Создание сценариев базы данных для управления версиями базы данных SQL Server

Question

В рамках ответственного программирования и управления версиями я хотел бы начать с изменения версий моей базы данных, особенно, так как я разрабатываю экземпляр своей базы данных, а затем перемещаю ее в производство. Я не нашел ничего, что действительно имеет смысл для меня, как это сделать. Я использую Visual Studio 2010 Pro в качестве моей IDE. Есть ли документ, который упрощает этот процесс и способен с легкостью обнаруживать изменения в базе данных? Или что я должен изменить в своем рабочем процессе, чтобы сделать это проще?

Answer 1

Один из способов, которым я успешно занимался в прошлом, - через Sql Source Control. Visual Studio не предлагает эту функцию для вас.

В качестве альтернативы вы можете использовать SSMS для создания сценариев базы данных для вас и сохранения в виде файла; то вы можете проверить скрипт. Вы бы выбрали, генерируете ли вы весь скрипт БД в одном файле или выполняете ли вы его на объекте по объектам. Синхронизирующая часть должна быть выполнена вами, выполнив ваши сценарии в процессе производства. В заключение a общий кошмар.

Redgate также предлагает Sql Compare, что отлично подходит для синхронизации баз данных. Взгляните на их продукты, если вы или ваша компания можете их себе позволить.

Answer 2

Сохраните ваши сценарии базы данных в SVN. Вот RefernceHow to use SVN Tortoise

ИЛИ

Сохраните сценарий базы данных в VSS. Вот ссылкаWhat is VSS ? How can we use that ?

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

Вы можете использовать продукт Red Gate также

EDIT

Как вы вытащить что то, что изменилось?

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

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

Загрузить последний файл с сервера.

Надеюсь, вы не используете операторы Drop для таблицы в сводном скрипте. Поскольку он удалит все записи из таблицы.

заявления падение будет иметь место для сохраняемого Pro, вид, функции и т.д.

Пожалуйста, обратите внимание, что вы должны запустить полную последнюю версию файла сценария базы данных на сервере с нижеуказанным планы действий

1. Remove Drop Statement for Schema DDL 
2. Add Drop/Create Statements for Stored Proc/Views 
3. Include Alter statements DML of schema. 

Надеюсь, это определенно поможет вам.

Answer 3

Мы используем собственное решение DB в доме, который приносит все инструменты, необходимые для надлежащего DB версий. Хотя я понимаю, что это может быть не идеальное решение для всех, я предлагаю вам взглянуть на него (это с открытым исходным кодом): bsn ModuleStore

Аспект версии выглядит так: инструмент может запускать скрипт SQL полуавтоматически, и он переформатирует исходный код в едином формате. Поэтому файлы всегда будут одинаковыми для одного и того же источника, независимо от того, когда и кем что-то было написано сценарием; поэтому он отлично работает с неблокирующими системами управления источниками (особенно SVN, Git или Mercurial).

переформатировать помещает все операторы в том же виде (например, дополнительные ключевые слова, такие как AS, INNER, OUTER и т.д. рассматриваются), сценарии все в «ДБО» схемы (даже если он был в другой один), помещает все идентификаторы в квадратные скобки ([something]), верхние регистры всех зарезервированных слов, отступы и т. д.

Помимо управления версиями часть времени выполнения инструмента может различать исполняемые DB и скрипты CREATE (исходный код DB) и применять автоматически обновляется для всех неразрушающих изменений (например, обновление индексов, ограничений, представлений, хранимых процедур, триггеров, пользовательских типов, новых таблиц и т. д.). Изменения Destructuve должны быть обработаны вручную (изменения таблицы, которые обычно требуют преобразования данных). Во время выполнения убедитесь, что все обновления выполняются в транзакции и откате, если результирующая БД не соответствует сценариям CREATE, поэтому вы получаете информацию о том, что БД находится именно на версии, требуемой приложением, даже если это был подделан вручную.

Кроме того, несколько «модулей» могут использоваться в одной базе данных. Каждый модуль хранится в виде схемы и не зависит от других схем, что позволяет добавлять или удалять модули из одного БД и избегать необходимости создания нескольких баз данных для разных частей приложения. Кроме того, использование схем для этого гарантирует, что нет столкновений имен.

Возможно, стоит отметить, что набор инструментов не имеет отношения к SMO, он является автономным.