Должны ли файлы базы данных (скрипты и т. Д.) Находиться под контролем исходного кода? Если да, то какой метод лучше всего сохранить и обновить там?

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

Какой подход лучше всего использовать для баз данных по управлению исходным кодом?

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

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

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

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

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

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

Да.

Какой лучший способ сохранить его и обновить его там?

Um. Напишите скрипт для построения схемы. Проверьте это после внесения изменений. Проверьте это перед запуском.

Трудно определить, что вы просите.

Написать формальные скрипты миграции схемы. Проверьте их после тестирования. Проверьте их, прежде чем запускать их.

Что еще там?

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

Эта органическая эволюция делает миграцию схемы более трудной, потому что нет «авторитетного» источника того, что должно быть там. Существует две слегка отличающиеся производственные версии, промежуточная версия, версия QA и восемь версий разработки. Все немного по-другому.

Если существовал единственный авторитетный источник, то миграция схемы - это просто разница между последней версией и этой версией.

да

Сценарии базы данных (ddl, dml) являются кодом. Весь код должен быть в системе контроля версий.

Миграции

• Использовать миграцию базы данных

Позволяет использовать одни и те же файлы БД в разработке, qa и выпусках.

• Выпуск в базу данных с номером выпуска

Храните номер релиза где-нибудь для аудита, многие хранят его в самой БД. Каждый выпуск будет состоять из миграций, которые приведут базу данных к правильной версии.

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

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

да

И, кроме того, вам нужны ветви .

Я использую Git для веток:

• для разработки для каждой функции (как мы делаем для обычной разработки остальной части приложения)

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

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

Я еще не нашел систему «все в одном» [для PostgreSQL], поэтому мне пришлось писать функции / сценарии для правильного переиндексации при объединении ветвей (например, любой индекс из производственной ветви не должен изменяться, поскольку клиенты полагаются на них, тогда как Индексы + внешние ключи из ветви разработки, которые пересекаются с производственным содержимым, должны быть переиндексированы: он не будет работать для всех приложений, но он охватывает все случаи нашего приложения, поэтому он достаточно хорош).

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

Для Java наша команда использует Flyway , который мы считаем очень простым в использовании и мощным.

Если вы работаете в Ruby, в Rails есть Migrations, которые также являются мощным способом решения этой проблемы.

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

Кроме того, программное обеспечение RedGate предлагает продукт под названием SQL Source Control , предназначенный для SQL Server. Я сам этим не пользовался, но один из моих коллег говорит, что это здорово.

Вот проблема, с которой я сталкивался много раз, когда нет контроля версий или управления изменениями в базах данных разработки. Программист А вносит изменения в таблицу, представление или процесс. Программист B вносит изменения в то же самое и перезаписывает то, что делал Программист A. Либо DBA восстанавливает производственную базу данных для разработки и перезаписывает изменения. Я видел, как такие вещи вызывают сильное горе столько раз, что это не смешно. И это только на системах разработки. При постановке / тестировании вещи могут быть очень запутанными, и даже производственные серверы могут быть вовлечены в это.

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

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

Для наших проектов PHP / MySQL мы использовали (когда-то) маленький инструмент под названием Ladder . Это разработано, чтобы облегчить органический рост базы данных с течением времени. Все миграции для проекта хранятся в revision / source / version control и отслеживаются вместе с кодом.

Он поддерживает добавление / изменение / удаление столбцов, выполнение запросов, добавление / удаление индексов, ограничений и т. Д. И т. Д. Он будет отслеживать состояние, в котором находится база данных, и применяет любые пропущенные миграции. Это также позволяет вам «отступить во времени», указав нужную вам миграцию. ( php ladder.php migrate 15)

О, и последнее дополнение - это различие в базе данных. Запустите diff-saveкоманду, добавьте и удалите некоторые столбцы из базы данных и выполните ее diffкоманду. Вы увидите автоматически сгенерированный код миграции, основанный на состоянии базы данных.

DataGrove решает некоторые из проблем, упомянутых здесь ( например , jfrankcarr ).

Он отслеживает все изменения в БД и позволяет сохранить версию состояния всей БД в хранилище. Затем он позволяет создавать несколько виртуальных копий одной и той же БД, поэтому каждый разработчик или администратор БД могут иметь свою собственную отдельную копию (каждая виртуальная копия может быть создана из другой версии). Это гарантирует, что никто не отменяет чужой код / ​​изменения. Каждая из виртуальных копий также отслеживается в одних и тех же репозиториях, поэтому все состояния БД можно легко разделить и воссоздать.

Я также хотел бы принести инструмент мониторинга, который также может быть использован в качестве инструмента управления версиями данных. Инструмент, о котором я говорю, это MONyog, на самом деле это инструмент мониторинга MySQL, но с небольшим взломом мы можем легко использовать его для контроля версий данных.

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

MONyog имеет функцию CSO (пользовательские объекты SQL), которая может отслеживать изменения в конкретном наборе данных. Добавление ОГО описано здесь . Теперь в разделе истории мониторинга MONyog вы можете получить изменения за определенный период времени. Лучше всего, это дает визуальный отчет на HTML-странице. Отчет будет выглядеть примерно так