Управление исходным кодом SQL Server [закрывается]

Недавно мы использовали Visual Studio Team System Database Edition , и я должен сказать, что он работал очень хорошо. Все хранимые процедуры хранятся в виде файлов и регистрируются в системе управления версиями и выходят из нее, и в ней есть инструменты для создания сценариев и т. Д.

Кроме того, в прошлом мы использовали сценарии, хранящиеся в виде текстовых файлов, которые возвращаются и удаляются. управления версиями. Правило заключалось в том, что вы должны были извлечь файл, затем отредактировать его, например, в Management Studio, сохранить его и вернуть обратно. В верхней части каждого файла сценария хранимой процедуры он удалял существующую хранимую процедуру, а затем используйте оператор CREATE, чтобы создать новый (обойдя проблему CREATE / ALTER). Затем у нас был инструмент, который запускал все сценарии в правильном порядке для создания пустой базы данных с нуля, а затем мы использовали RedGate. s SQL Compare продукт для создания сценария для обновления существующих баз данных. Я признаю, что это было утомительно.

Примерно в то же время я работал над системой с примерно 10 другими разработчиками, и они внедрили строгую процедуру управления изменениями базы данных. Было очень много приложений, которые все зависели от набора из 2 или 3 баз данных. Каждый раз, когда схема базы данных должна была измениться (здесь мы говорим только о таблицах, столбцах и представлениях), создавался документ, объясняющий это изменение, а затем была матрица, в которой перечислялись изменения и какие приложения, по нашему мнению, это повлияет . Затем документ был распространен, и его должен был просмотреть кто-то, кто отвечал за каждое приложение, и им пришлось искать в своем приложении все, что могло затронуть его, и т. Д. Это была долгая и трудная процедура, но она работала. Тем не мение, сохраненные процессы просто хранились в виде текстовых файлов в системе управления версиями.

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

• Проверял чтобы увидеть, существует ли база данных, а если нет, создайте ее
• Убедитесь, что все таблицы существуют, а если нет, создайте их
• Убедитесь, что все столбцы существуют, и если нет, добавьте их

Каждый раз, когда я необходимо изменить схему, я бы просто добавил больше кода в конец кода запуска, чтобы изменить схему по мере необходимости, позаботившись о переносе любых существующих данных. Преимущество этого было в том, что вы могли просто удалить и переустановить новую версию программного обеспечения, и это автоматически обновило бы существующую базу данных до последней версии. Установка, обновление и обслуживание были мечтой. Это не сработает для большего "