В какой момент кто-то должен решить переключить системы баз данных

Это зависит от того, что вы делаете. Вы можете переключиться, если:

• Вам нужна большая масштабируемость или лучшая производительность - скажем, от SQLite до SQL Server или Oracle.
• Вам нужен доступ к более конкретным типам данных.
• Вам необходимо поддержать клиента, который работает только с определенной базой данных.
• Вам нужны лучшие инструменты DBA.
• Ваше приложение использует другую платформу, где ваша база данных больше не работает или библиотеки не работают.
• У вас есть возможность / время / бюджет, чтобы действительно внести изменения. В зависимости от ситуации миграция может быть более крупным проектом, чем все в проекте до этого момента. Подобные миграции - отличные места для внесения несоответствий или потери данных, поэтому требуется большая осторожность.

Есть еще много причин для переключения, и все зависит от ваших требований и атрибутов баз данных.

BrianLy попал в точку, но я бы также добавил, что вы можете в конечном итоге использовать разные базы данных на разных уровнях разработки. Разработчики нередко используют SQLite на своих рабочих станциях, когда они кодируют для своего личного сервера разработки, а затем используют промежуточные и / или производственные сайты с использованием другого инструмента базы данных.

Конечно, если вы используете расширения или возможности, специфичные для определенного инструмента базы данных (скажем, PostGIS в PostGreSQL), то, очевидно, это не сработает.

Вы должны переключить базы данных на этапе 2.3433, за 3 секунды до левой ветви дендрита 8,151,215.

Я бы посоветовал вам переключать базы данных, когда у вас есть причина для этого. Если ваша существующая база данных работает в соответствии с вашими ожиданиями, поддерживает нагрузку, которую возлагают на нее ваши производственные системы, имеет функции, которые вам требуются в ваших приложениях, и вам это не надоедает, зачем менять? Однако, если вы обнаружите, что ваше приложение не масштабируется, или вы разрабатываете приложение, которое имеет высокие требования к нагрузке или масштабируемости, и ваше исследование показывает, что ваша текущая платформа базы данных слабая в этой области, или, как уже упоминалось, вам нужны некоторые пространственный анализ или функция, которая есть в конкретной базе данных, ну вот и все.

Еще одно соображение может заключаться в использовании инструмента ORM, не зависящего от базы данных, который может позволить вам свободно экспериментировать с различными платформами баз данных с простой настройкой конфигурации. Это побудило нас подумать о том, чтобы попробовать что-то новое в отделе баз данных. Если наше приложение может обрабатывать любую БД, которую может обрабатывать ORM, зачем платить лицензионные сборы за коммерческую базу данных, если БД с открытым исходным кодом работает так же хорошо, как и требуемые уровни производительности?

Суть в том, что с базами данных или любой другой технологией, я думаю, не существует «бизнес-правил», которые подскажут вам, когда пора переходить - ваш сценарий скажет вам, что пора переходить, потому что что-то в вашем решении будет не совсем правильно, и если вы не на этом этапе, не нужно ничего менять.