как управлять обновлениями структуры sql

Question

Как люди рекомендуют управлять обновлениями структуры базы данных?

например. добавлены новые функции, требующие изменения существующих таблиц, добавления новых и т. д.

Есть ли хорошее программное обеспечение или это случай написания операторов типа ALTER.

Answer 1

Хотя существует программное обеспечение, которое может анализировать различия между двумя схемами (RedGate SQL Compare) и генерировать необходимые сценарии изменений, я предпочитаю писать собственные операторы изменений базы данных. Таким образом, я полностью контролирую то, что меняется - ни больше, ни меньше. Сверните изменения в скрипт Install.sql или что-то в этом роде для каждой версии базы данных, чтобы вы могли просто запустить этот скрипт и обновить базу данных.

Это позволяет легко переносить изменения из разработки в тестирование в производство.

См .: Развертывание баз данных SQL Server из тестового в живое

Answer 2

Я собираюсь добавить одну вещь. Недостаточно написать оператор alter table, чтобы изменить структуру таблицы. Если вы изменяете структуру таблицы, перед запуском лучше убедиться, что вы точно знаете, какие другие представления, функции, таблицы, хранимые процедуры, триггеры, пакеты служб SSIS (для DTS) (для SQL Server) и динамический код из приложений будут затронуты изменения. Если вы не совсем уверены, какие другие объекты могут быть затронуты, вы не готовы изменить таблицу. Я видел слишком много сбоев критически важных бизнес-функций, потому что кто-то случайно изменил структуру таблицы, не задумываясь о том, что еще использовало эту структуру. Если вы планируете внести структурные изменения в базу данных, я предлагаю вам ознакомиться с рефакторингом базы данных, прежде чем вы это сделаете.

Вот хорошая книга для начала: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533

Answer 3

Если вы не хотите писать все операторы alter вручную, в SQL Server Management Studio есть графический интерфейс для работы со всеми этими вещами. Вы можете использовать графический интерфейс, а затем посмотреть на сценарий, который он генерирует, и перейти оттуда, если вы хотите какой-то быстрый, гибридный подход.

Answer 4

Вы не упоминаете объем своего приложения или количество разработчиков и т. Д., Поэтому немного сложно дать какие-либо рекомендации. Однако, если ваша разработка состоит из нескольких параллельных проектов и нескольких разработчиков, и вы копируете из разработки в производство, я бы порекомендовал что-то вроде следующего:

• реализовать 3 "зоны": dev, qa, production.
• разработать все изменения в dev, создать все изменения в скриптах, использовать что-то вроде cvs для отслеживания изменений на всех объектах
• когда изменения будут готовы и протестированы, запустите ваши скрипты в qa, это проверит ваши скрипты и установит процедуру
• когда будешь готов, запусти свои скрипты и установи процедуру на производстве

примечание: qa практически идентична производственной, за исключением внесенных изменений, ожидающих их окончательной производственной установки. dev содержит любые изменения в работе, дополнительную отладку и т. д. Вы можете периодически восстанавливать производственную резервную копию на qa и dev для повторной синхронизации (просто убедитесь, что все разработчики знают об этом и планируют соответственно), поскольку (в зависимости от количества разработчики) они (производство против qa против dev) начнут испытывать больше различий со временем.