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

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

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

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

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

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
22
0
12 237
12

Ответы 12

Вариант создания скрипта:

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

Используйте стандартные методы контроля версий, чтобы хранить, разветвлять, маркировать версии и просматривать истории ваших объектов.

При обновлении действующей базы данных (где вы не хотите терять данные) создайте пустую вторую копию базы данных в новой версии и используйте такой инструмент, как текст ссылки от Red-Gate.

Плюсы: Изменения в файлах отслеживаются стандартным исходным кодом, как и

Минусы: Использование сторонних инструментов вручную для выполнения фактических обновлений (без / небольшая автоматизация)

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

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

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

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

Вариант сценария обновления

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

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

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

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

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

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

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

Я уверен, что они сохраняются только с точки зрения документации SOX, так что вам есть что показать аудиторам (если они спросят), КАКИЕ изменения были внесены.

Brian Schmitt 04.12.2008 17:17

Конечно, было бы не менее важно суметь показать СЕБЕ, какое изменение было произведено.

Brett Hannah 04.12.2008 17:34

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

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

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

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

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

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

Он поддерживает базовый сценарий создания, за которым следует проверка сценариев изменения и сохранение таблицы версий в базе данных.

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

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

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

Шри Рамулу [email protected]

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

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

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

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

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

Он немного староват, но концепции все еще существуют. Хорошо читать!

Как открытый вопрос

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

Вещи, которые я тестировал: Файловая обработка скриптов в git с использованием GitlabCI

  • Это не работает, возникают коллизии, и часть администрирования должна выполняться вручную в случае аварии, а часть разработки слишком сложна

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

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

  • Использование репозитория Не удалось управлять частью DRP Я не мог должным образом контролировать резервные копии Я не думаю, что иметь резервные копии на одном сервере - хорошая идея, и вы генерируете высокие задержки для процесса.

  • This was what worked best

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

  • Мультиплатформенный

  • Использование базы данных development-Production-QA

  • Всегда поддерживайте перед каждой модификацией

  • Управление открытым репозиторием для контроля изменений

  • Мульти-сервер

  • Деактивировать / активировать доступ к веб-странице или приложению через конечные точки

  • исходный проект находится в:

  • In case the comment manager reads this part, I understand the self-promotion but please just remove this part and leave the rest since I think it complies with the answer to the question reacted in the post ... https://hub.docker.com/r/arelis/gitdb

Я надеюсь, что это дойдет до вас, поскольку я вижу, что несколько

Другие вопросы по теме