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

Question

В настоящее время мы изучаем, как мы храним наши скрипты базы данных (таблицы, процедуры, функции, представления, исправления данных) в Subversion, и мне было интересно, есть ли консенсус относительно того, какой подход лучше?

Некоторые факторы, которые нам необходимо учитывать, включают:

• Должны ли мы установить скрипты 'Create' или инкрементные изменения с помощью скриптов 'Alter'
• Как мы отслеживаем состояние базы данных для данного выпуска
• Должно быть легко создать базу данных с нуля для любой версии выпуска
• Если в базе данных существует таблица, в которой перечислены скрипты, которые с ней работали, или версия базы данных и т. Д.

Очевидно, это довольно открытый вопрос, поэтому мне интересно услышать, чему их научил опыт людей.

Answer 1

После нескольких итераций выбранный нами подход был примерно таким:

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

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

У нас также есть программа (написанная на Python), которая сканирует каталог, полный сценариев, и собирает их в один большой сценарий. Он анализирует SQL только для того, чтобы вывести зависимости между таблицами (на основе ссылок на внешние ключи) и упорядочить их соответствующим образом. В результате получается монстр-SQL-скрипт, который за один раз приводит базу данных в соответствие со спецификацией. Программа сборки сценариев также вычисляет хэш MD5 входных файлов и использует его для обновления номера версии, записанного в специальную таблицу в последнем сценарии в списке.

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

Answer 2

По этой ссылке есть интересная статья: https://blog.codinghorror.com/get-your-database-under-version-control/

Он поддерживает базовый сценарий 'create' с последующей проверкой сценариев 'alter' и сохранением таблицы версий в базе данных.

Answer 3

Я склонен проверять исходный скрипт создания. Затем в моей базе данных есть таблица DbVersion, и мой код использует ее для обновления базы данных при первоначальном подключении, если это необходимо. Например, если моя база данных находится на версии 1, а мой код - на версии 3, мой код будет применять операторы ALTER, чтобы перенести ее в версию 2, а затем в версию 3. Для этого я использую простую инструкцию переключения при падении.

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

Это не очень хорошая идея для всех программ, но возможны варианты.

Answer 4

Опция сценария обновления

Сохранять каждое изменение в базе данных как отдельный скрипт sql. Сохраните каждую группу изменений в пронумерованной папке. Используйте сценарий, чтобы применить изменения к папке за раз и записать в базу данных, какие папки были применены.

Плюсы: Полностью автоматизированный, тестируемый путь обновления

Минусы: Трудно увидеть полную историю каждого отдельного элемента Приходится строить новую базу данных с нуля, пройдясь по всем версиям

Answer 5

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

Ответы на каждый из ваших факторов:

• Хранить CREATE скрипты. Если вы хотите оформить заказ на версию x.y.z, было бы неплохо просто запустить скрипт create для немедленной настройки базы данных. Вы могли бы также добавлять сценарии ALTER для перехода от предыдущей версии к следующей (например, вы фиксируете версию 3, которая содержит сценарий CREATE версии 3 и сценарий изменения 2 и 3).
• См. Решение по миграции на Rails. В основном они хранят номер версии таблицы в базе данных, так что вы всегда знаете.
• Использовать скрипты CREATE.
• Использование номеров версий, вероятно, было бы наиболее распространенным решением & mdash; имена сценариев и пути могут меняться со временем.

Мои два цента!

Answer 6

Мы создаем ветку в Subversion, и все изменения базы данных для следующего выпуска записываются и регистрируются. Все сценарии повторяются, поэтому вы можете запускать их несколько раз без ошибок.

Мы также связываем сценарии изменений с выпуском элементов или идентификаторов ошибок, чтобы при необходимости можно было сохранить набор изменений. Затем у нас есть автоматизированный процесс сборки, который просматривает выпуски проблем, которые мы выпускаем, извлекает сценарии изменений из Subversion и создает один файл сценариев SQL, в котором все изменения отсортированы соответствующим образом.

Этот единственный файл затем используется для продвижения изменений в средах Test, QA и Production. Автоматизированный процесс сборки также создает записи базы данных, документирующие версию (ветка плюс идентификатор сборки). Мы считаем, что это лучший подход для корпоративных разработчиков. Подробнее о том, как мы это делаем, можно узнать ЗДЕСЬ

Answer 7

Есть интересная статья с новым URL: https://blog.codinghorror.com/get-your-database-under-version-control/

Это немного старо, но понятия все еще там. Приятного чтения!

Answer 8

В моем случае я создаю скрипт SH для этой работы: https://github.com/reduardo7/db-version-updater

Answer 9

для каждого выпуска нам нужно предоставить один файл update.sql, который содержит все новые сценарии таблиц, операторы alter, новые / измененные пакеты, роли и т. Д. Этот файл используется для обновления базы данных с 1 версии до 2.

Что бы мы ни включали в файл update.sql выше одного, все эти утверждения должны идти к отдельным соответствующим файлам. как оператор alter должен переходить в таблицу как новый столбец (сценарий таблицы должен быть изменен, а оператор Alter не добавляется после создания сценария таблицы в файле) так же, как новые таблицы, роли и т. д.

Так что всякий раз, когда пользователь хочет обновить, он будет использовать первый файл update.sql для обновления. Если он хочет собрать с нуля, он будет использовать build.sql, который уже имеет все вышеприведенные операторы, он синхронизирует базу данных.

Sriramulu Sriramis4u@yahoo.com

Answer 10

Наша компания регистрирует их просто потому, что кто-то решил включить это в какой-то документ SOX, который мы делаем. Это не имеет никакого смысла для меня, кроме как в качестве справочного документа. Я не вижу времени, когда мы вытаскиваем их и пытаемся использовать их снова, и если бы мы это сделали, мы должны были бы знать, какой из них побежал первым, а какой - после чего. Резервное копирование базы данных гораздо важнее, чем сохранение сценариев Alter.