План контроля версий баз данных: горячий или нет?

Question

Основываясь на чтении в Интернете, переполнении стека и, в основном, этих статьях о версиях БД, которые были связаны с ужасом кодирования, я попытался написать план для управления версиями базы данных 8. летний веб-сайт php mysql.

Database Version Control plan
- Create a db as the "Master Database"
- Create a table db_version (id, script_name, version_number, author, comment, date_ran)   
- Create baseline script for schema+core data that creates this db from scratch, run this on Master Db
- Create a "test data" script to load any db with working data
- Modifications to the master db are ONLY to be made through the db versioning process
- Ensure everyone developing against the Master Db has a local db created by the baseline script
- Procedures for commiting and updating from the Master Db
    - Master Db Commit
        - Perform a schema diff between your local db and the master db
        - Perform a data diff on core data between your local db and master db
        - If there are changes in either or both cases, combine these changes into an update script
        - Collect the data to be added to a new row in db_version table, and add an insert for this into the script
            - new version number = latest master db version number +1
            - author
            - comment
        - The script must be named as changeScript_V.sql where V is the latest master db version +1
        - Run the script against the master db
        - If the script executed succesfully, add it to the svn repository
        - Add the new db_version record to your local db_version table      
    - Update from Master Db
        - Update your local svn checkout to have all the latest change scripts available
        - compares your local db_version table to the master db_version table to determine which change scripts to run
        - Run the required change scripts in order against your local db, which will also update your local db_version table

Мой первый вопрос: это звучит правильно?
Мой второй вопрос: процесс фиксации кажется немного сложным, чтобы выполнять его чаще, чем раз в день. Есть ли способ надежно автоматизировать это? Или мне не следует совершать изменения базы данных достаточно часто, чтобы это имело значение?

Answer 1

Глядя на ваши предложения, это не кажется чем-то выполнимым или практичным. Я работал в компании, где мы использовали более 1 тыс. Таблиц на базу данных (очень сложная система), и все это работало нормально, как это:

• Пусть один человек отвечает за БД (назовем его DBPerson) - каждое изменение сценария / базы данных должно проходить через него. Это позволит избежать ненужных изменений и некоторых «упущений» из проблем (например, если кто-то переместит индекс для лучшей работы для своего запроса, он может уничтожить работу других людей, возможно, кто-то создаст таблицу, которая является полностью избыточной и ненужной , так далее...). Это будет поддерживать чистоту и эффективность БД. Даже если это кажется слишком большой работой для одного парня (или его заместителя), на самом деле это не так - БД обычно редко меняется.
• Каждый скрипт должен пройти проверку через DBPerson
• Когда сценарий утвержден, DBPerson назначает номер и помещает его в папку «update» / svn (...) с соответствующей нумерацией (как вы предлагали, например, с добавочными номерами).
• Далее, если у вас есть какая-то непрерывная интеграция, сценарий подбирается и обновляет базу данных (если у вас нет непрерывной интеграции, сделайте это вручную).
• Не хранить весь скрипт базы данных, со всеми данными в скрипте. Вместо этого сохраните фактическую базу данных. Если у вас есть ветви решения - каждая ветка имеет собственную базу данных, или вы всегда можете разделить сценарии обновления для каждой из ветвей, чтобы вы могли выполнить откат / пересылку в другую ветку. Но я действительно рекомендую иметь отдельную базу данных для каждой ветви.
• Иметь одну базу данных всегда с данными по умолчанию (без изменений) - для нужд юнит-тестов, регрессионных тестов и т. Д. Всякий раз, когда вы проводите тесты, делайте их на копии этой базы данных. Вы можете даже поставить ночную очистку тестовых баз данных с основной (при необходимости, конечно).

В такой среде у вас будет несколько версий базы данных:

• База данных разработчиков (локальная) - та, которую разработчик использует для проверки своей работы. Он всегда может скопировать с Мастера или Мастера теста.
• Основная база данных - база данных со всеми значениями по умолчанию, может быть, полупустая, если вы выполняете повторное развертывание для новых клиентов.
• Test Master database - основная база данных, заполненная тестовыми данными. Все скрипты, которые вы запускали на Мастере, вы запускали и здесь.
• База данных в процессе тестирования - скопированная из Test Master и использованная для тестирования - перезаписывается перед любым новым тестом.
• Если у вас есть филиалы (аналогичная база данных с небольшой разницей для каждого из клиентов), то вы будете иметь то же самое, что и выше для каждой ветви ...

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