При разработке, будь то его веб или рабочий стол, в какой момент разработчик должен перейти с SQLite, MySQL, MS SQL и т. Д.
Это зависит от того, что вы делаете. Вы можете переключиться, если:
- Вам нужна большая масштабируемость или лучшая производительность - скажем, от SQLite до SQL Server или Oracle.
- Вам нужен доступ к более конкретным типам данных.
- Вам необходимо поддержать клиента, который работает только с определенной базой данных.
- Вам нужны лучшие инструменты DBA.
- Ваше приложение использует другую платформу, на которой ваша база данных больше не работает или библиотеки не работают.
- У вас есть возможность / время / бюджет, чтобы действительно внести изменения. В зависимости от ситуации, миграция может быть большим проектом, чем все в проекте до этого момента. Подобные миграции являются отличным местом для внесения несоответствий или потери данных, поэтому требуется большая осторожность.
Есть еще много причин для переключения, и все это зависит от ваших требований и атрибутов баз данных.
BrianLy ударил по голове, но я бы также добавил, что вы можете использовать разные базы данных на разных уровнях разработки. Разработчики нередко используют SQLite на своих рабочих станциях, когда они программируют на своем персональном сервере разработки, а затем используют промежуточные и / или рабочие сайты с использованием другого инструмента базы данных.
Конечно, если вы используете расширения или возможности, специфичные для определенного инструмента базы данных (скажем, PostGIS в PostGreSQL), то, очевидно, это не сработает.
Вы должны переключить базы данных на этапе 2.3433, 3ps до левой ветви дендрита 8,151,215.
Вы должны переключать базы данных, когда у вас есть причина для этого, был бы мой совет. Если ваша существующая база данных соответствует вашим ожиданиям, поддерживает нагрузку, которую несут ваши производственные системы, имеет функции, которые требуются в ваших приложениях, и вам это не надоедает, зачем менять? Однако, если вы обнаружите, что ваше приложение не масштабируется, или вы разрабатываете приложение, которое предъявляет высокие требования к нагрузке или масштабируемости, и ваши исследования показывают, что ваша текущая платформа баз данных слаба в этой области, или, как уже упоминалось, вам нужны некоторые пространственный анализ или особенность, которую имеет конкретная база данных, ну вот и все.
Еще одним соображением может стать использование независимого от базы данных инструмента ORM, который может позволить вам свободно экспериментировать с различными платформами баз данных с помощью простого параметра конфигурации. Это послужило толчком для того, чтобы мы могли попробовать что-то новое в отделе БД. Если наше приложение может обрабатывать любую БД, с которой может справиться ORM, зачем платить лицензионные сборы за коммерческую базу данных, если БД с открытым исходным кодом работает так же хорошо, как и для требуемых уровней производительности?
Суть в том, что с базами данных или любыми другими технологиями, я думаю, что не существует «бизнес-правил», которые сообщали бы вам, когда пришло время переключаться - ваш сценарий скажет вам, что пришло время переключаться, потому что что-то в вашем решении будет не совсем правильно, и если вы не в этот момент, не нужно менять.