Рекомендации по удалению баз данных

Question

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

В нашей компании некоторые разработчики используют приложение для анализа разности баз данных, чтобы выяснить различия между тестовой и производственной средой. Некоторые разработчики хранят t-sql каждого изменения, которое они сделали на db, как и я.

Интересно, что вы делаете для развертывания изменений db в производственной среде. Почему вы так выбираете? Или что нужно сделать?

Спасибо за ответы!

Answer 1

У нас есть наш db под контролем источника. Любые изменения отслеживаются таким образом. Все остальное было бы кошмаром.

Джеффа статья о нем тоже - http://blog.codinghorror.com/get-your-database-under-version-control/

В зависимости от настроек и баз данных, Мастер публикации базы данных - http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard - может быть очень полезными.

Answer 2

Сценарии и сохранение всех изменений, внесенных вами в SQL, являются наилучшим способом ИМО.

Answer 3

В одном проекте у меня есть все мои изменения в DB в сценариях DDL. Эти сценарии содержат инструкции SQL, необходимые для обновления БД до определенной версии. Имя файла сценария также содержит номер версии БД, на которую будет обновляться БД (_versionnumber.sql)

Рядом с этим у меня есть небольшое приложение, которое обновляет БД до последней версии, путем выполнения этих файлов сценариев в правильном порядке (от текущей версии DB до последнего файла скрипта).

Для новых проектов я теперь использую Migrator.NET. Эта структура позволяет записывать изменения БД в классы C#. В структуре есть консольное приложение, с помощью которого вы можете выполнять изменения БД, а также использовать его с msbuild.

Answer 4

Каждый объект базы данных хранится в отдельном файле в системе контроля версий. Система контроля версий может содержать файлы, как в этом примере:

|- tables 
    |- employees.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

Всякий раз, когда вы изменяете какой-нибудь объект БД, то вы должны также изменить соответствующий SQL файл (DDL) в системе управления версиями. Например, если вы изменяете пакет contract_api, тогда вы обновляете файл contract_api.sql. Поскольку этот файл был изменен - ​​он может быть установлен, скажем, механизмом непрерывной интеграции.

НО, как вы знаете, существуют сценарии DDL, которые нельзя выполнить дважды. Например, скрипт CREATE TABLE mytable ... может выполняться только один раз. И если ваша система уже находится в производстве, вы не можете позволить себе команду «DROP TABLE mytable» в заголовке вашего сценария «CREATE TABLE ...». Поэтому для производственных систем вам нужно создать так называемые дельта-скрипты , которые будут доставлять только изменения. В этом случае вы можете просто создать новый файл, называемый employee_upd01.sql, который содержит инструкцию «ALTER TABLE mytable ADD COLUMN ...».

Через некоторое время ваше хранилище может выглядеть следующим образом:

|- tables 
    |- employees.sql 
    |- employees_upgr20091001.sql 
    |- employees_upgr20091004.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

И это нормально, потому что: 1) когда необходимо доставить постепенные изменения сегодняшними в базу данных - развернуть файлы, которые были изменены сегодня 2) если вам нужно развернуть чистую установку вашей системы - вы запускаете все сценарии по порядку, например первый employees.sql, затем employees_upgr20091001.sql и т.д.

Поскольку каждый объект DB находится в отдельном файле в системе контроля версий, у вас есть хороший контроль над всеми изменениями.