Рекомендации по изменению рабочих процессов в базе данных SQL Server

Question

Фон

В моей группе 4 базы данных SQL Server:

• Производство
• УАТ
• Тест
• Dev

Я работаю в среде разработчиков. Когда приходит время продвигать объекты, над которыми я работал (таблицы, представления, функции, хранимые процедуры), я делаю запрос моего менеджера, который продвигает Test. После тестирования она отправляет запрос администратору, который продвигает UAT. После успешного пользовательского тестирования тот же администратор продвигает в производство.

Проблема

Весь процесс неудобен по нескольким причинам.

1. Каждый человек должен вручную отслеживать свои изменения. Если я обновляю, добавляю, удаляю любые объекты, которые мне нужны, чтобы отслеживать их, чтобы мой запрос на продвижение содержал все, что я сделал. Теоретически, если я что-то пропускаю, тестирование или UAT должны его поймать, но это не совсем точно, и в любом случае это пустая трата времени тестера.
2. Множество изменений, которые я делаю, являются итеративными и выполняются в графическом интерфейсе, что означает, что нет записи о том, какие изменения я внес, только конечный результат (по крайней мере, насколько я знаю).
3. Мы находимся на довольно ранних стадиях построения витрины данных, поэтому большинство внесенных изменений, по крайней мере, в подсчете, незначительны: изменение типа данных для столбца, изменение имен таблиц как мы кристаллизуем, для чего они будут использоваться, настраиваем функции и хранимые процедуры и т. д.

Вопрос

Люди занимались такой работой десятилетиями, поэтому я думаю, что должен быть намного лучший способ управлять процессом. Что бы мне понравилось, если бы я мог запустить diff между двумя базами данных, чтобы увидеть, как структура отличается, использовать этот diff для генерации сценария изменений, использовать этот сценарий изменений в качестве моего запроса на продвижение. Это возможно? Если нет, есть ли другие способы организовать этот процесс?

Для справки, мы на 100% Microsoft, только что обновив все до SQL Server 2008, поэтому любые инструменты, доступные в этом пакете, будут честной игрой.

---

Я должен уточнить, что я не обязательно ищу инструменты сравнения. Если это лучший способ синхронизации наших сред, то это хорошо, но если есть лучший способ, я ищу это.

Пример, делающий то, что я действительно хочу, это миграция в Ruby on Rails. Простой простой синтаксис, все изменения хорошо документированы автоматически, и по умолчанию определить, какие миграции необходимо выполнить, почти тривиально просто. Я хотел бы, чтобы было что-то подобное для SQL Server.

Мое идеальное решение: 1) легко и 2) сложно все испортить. Рельсы Миграции оба; все, что я до сих пор делал на SQL Server, - ни то, ни другое.

Answer 1

Контроль версий и ваша база данных

Корень всего зла вносит изменения в пользовательский интерфейс. SSMS - это инструмент DBA, а не разработчик. Разработчики должны использовать scripts для внесения любых изменений в модель / схему базы данных. Управление версиями ваших метаданных и обновление сценария с каждой версии N до версии N + 1 - это способ only , который доказал свою надежность. Это решение, которое развертывает сам SQL Server, чтобы отслеживать изменения метаданных (изменения базы данных ресурса).

Инструменты сравнения, такие как SQL Compare или vsdbcmd и файлы .dbschema из проектов VS Database, являются лишь последними прибежищами для магазинов, которые не могут сделать правильный версионный подход. Они работают в простых сценариях, но я вижу, что все они терпят неудачу в серьезных развертываниях. Просто нельзя доверять инструменту для внесения изменений в таблицу + 5 ТБ, если инструменты пытаются скопировать данные ...

Answer 2

В нашей команде мы обрабатываем изменения базы данных следующим образом:

• Мы (повторно) создаем скрипт , который создает полную базу данных и регистрирует ее в системе контроля версий вместе с другими изменениями. У нас есть 4 файла: таблицы, пользовательские функции и представления, хранимые процедуры и разрешения. Это полностью автоматизировано - для создания сценария требуется только двойной щелчок.
• Если разработчик должен внести изменения в базу данных, он делает это на своей local db .
• Для каждого изменения мы создаем сценарии обновления . Их легко создать: разработчик восстанавливает сценарий БД своего локального БД. Все изменения теперь легко идентифицировать благодаря контролю версий. Большинство изменений (новые таблицы, новые представления и т. Д.) Можно просто скопировать в сценарий обновления, другие изменения (например, добавление столбцов) необходимо создать вручную.
• Сценарий обновления протестирован либо в нашей общей базе данных разработчиков, либо путем отката локальной базы данных до последней резервной копии, которая была создана перед началом изменения базы данных. Если оно прошло, пришло время зафиксировать изменения.
• Сценарии обновления следуют соглашению о присвоении имен , поэтому все знают, в каком порядке их выполнять.

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

Важными моментами являются:

• Структура базы данных изменена только сценариями , за исключением базы данных локального разработчика. Это важно.
• Версии сценариев SQL с помощью системы контроля версий - базу данных можно создать, как это было в любой момент в прошлом
• резервные копии базы данных создаются регулярно - по крайней мере, перед внесением изменений в db
• изменения в БД могут быть сделаны быстро, потому что сценарии для этих изменений создаются относительно легко.

Однако, если у вас есть много веток разработки для ваших проектов, это может не сработать.

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

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

Answer 3

Согласитесь, что SQL Compare - замечательный инструмент.

Однако мы не вносим никаких изменений в структуру базы данных или объекты, которые не являются сценариями и не сохранены в системе контроля версий, как и весь другой код. Тогда вы точно знаете, что относится к рекламируемой вами версии, потому что у вас есть сценарии для этой конкретной версии.

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

Answer 4

Для вас доступно несколько инструментов. Один из Red-Gate называется SQL Compare . Потрясающе и очень рекомендуется. SQL Compare позволит вам различать схемы между двумя базами данных и даже создавать сценарии изменения SQL для вас.

Обратите внимание, что они уже некоторое время работают над продуктом управления версиями SQL Server.

Другой (если вы магазин Visual Studio) - это функции сравнения схем и данных, входящие в состав Visual Studio (не знаю, какие версии).

Answer 5

RedGate продает SQL Compare , отличный инструмент для генерации сценариев изменений.

Visual Studio также имеет выпуски, которые поддерживают сравнение баз данных. Ранее это называлось Database Edition .

Там, где я работаю, мы давно отменили разделение Dev / Test / UAT / Prod в пользу очень быстрого цикла выпуска . Если мы поместим что-то сломанное в производство, мы быстро это исправим. Наши клиенты, безусловно, счастливее, но в корпоративном предприятии, предотвращающем риски, это может быть трудно продать.

Answer 6

Я согласен с комментариями, сделанными marapet, где каждое изменение должно быть написано в сценарии.
Однако проблема, с которой вы можете столкнуться, заключается в создании, тестировании и отслеживании этих сценариев.
Посмотрите на механизм исправлений, используемый в DBSourceTools.
http://dbsourcetools.codeplex.com

Он был специально разработан, чтобы помочь разработчикам получить базы данных SQL-сервера под контролем исходного кода.

Этот инструмент позволит вам создать базу данных в определенной точке и создать именованную версию (v1).
Затем создайте цель развертывания и увеличьте указанную версию до версии v2.
Добавьте сценарии исправлений в каталог исправлений для любых изменений схемы или данных.
Наконец, проверьте базу данных и все исправления в элементе управления исходным кодом, чтобы распространять их вместе с разработчиками.

Это дает вам повторяющийся процесс тестирования всех исправлений, которые будут применены от v1 до v2.
DBSourceTools также имеет функции, помогающие вам создавать эти сценарии, то есть инструменты сравнения схем или данных сценариев.

Как только вы закончите, просто отправьте все файлы в каталоге заплаток вашему администратору базы данных для обновления с v1 до v2.

Веселитесь.

Answer 7

1. Хранить версию базы данных в таблице версий
2. Сохранить имя файла сценария, который был успешно применен
3. Сохраните сумму md5 для каждого примененного сценария sql. Он должен игнорировать пробелы при расчете суммы md5. Должно быть эффективным.
4. Хранить информацию о том, кто применил сценарий Сохранить информацию о том, когда был применен сценарий
5. База данных должна быть проверена при запуске приложения
6. Новый скрипт sql должен применяться автоматически
7. Если сумма md5 уже примененного сценария изменилась, выдается ошибка (в производственном режиме)
8. Когда скрипт выпущен, его нельзя менять. Это должно быть неизменным в производственной среде.
9. Скрипт должен быть написан таким образом, чтобы его можно было применять к различным типам баз данных (см. Liquibase)
10. Поскольку большинство операторов ddl автоматически фиксируются в большинстве баз данных, лучше всего иметь один оператор ddl для каждого сценария SQL.
11. Оператор DDL sql должен выполняться таким образом, чтобы его можно было выполнить несколько раз без ошибок. Действительно помогает в режиме разработки, когда вы можете редактировать скрипт несколько раз. Например, создайте новую таблицу, только если она не существует, или даже удалите таблицу перед созданием новой. Это поможет вам в режиме разработки, со скриптом, который еще не был выпущен, измените его, очистите сумму md5 для этого скрипта, запустите его снова.
12. Каждый сценарий sql должен выполняться в отдельной транзакции.
13. Триггеры / процедуры должны быть удалены и созданы после каждого дБ обновить.
14. Скрипт Sql хранится в системе управления версиями, такой как svn
15. Имя скрипта содержит дату, когда он был зафиксирован, идентификатор существующей (jira) проблемы, небольшое описание
16. Избегайте добавления функциональности отката в скриптах (liquibase позволяет это делать). Это усложняет их написание и поддержку. Если вы используете ровно один оператор ddl на скрипт, а операторы dml выполняются в транзакция, даже если скрипт не удастся, не будет большой проблемой для решить

Answer 8

Еще один инструмент "Diff" для баз данных:

http://www.xsqlsoftware.com/Product/Sql_Data_Compare.aspx