Обробка схеми бази даних змінюється при натисканні нових версій

Під час важких розробок схема бази даних змінюється як швидко, так і постійно, і до того моменту, коли відбувається тижневий поштовх до бета-версії, схема настільки змінилася, що єдиним розумним варіантом є занурення всіх таблиць, які я можу і скопіюйте нові версії з моєї бази даних розробників. Очевидно, що після запуску це не спрацює, оскільки виведення даних про виробництво є рецептом катастрофи, тому мені було цікаво, які існують стратегії управління змінами схеми бази даних від однієї версії / редакції до іншої?

Деякі я знайшов або пережив:

1. Прямий нук-енд-дамп із однієї бази даних в іншу (що я зараз роблю)
2. Підтримка файлу UPDATE.sql з операторами SQL, які запускаються або через скрипт, або вручну.
3. Підтримка файлу update.php з відповідним значенням "db-схема-версія" в активній базі даних

Третій варіант видається найбільш розумним, але все ще існує можливість погано побудованого SQL-запиту не виконати середину скрипту, залишаючи базу даних у напів оновленому стані, що потребує відновлення резервної копії.

Здається, це не проблема, але це трапляється, оскільки ми, як команда, використовуємо phpMyAdmin, і я, здається, навіть не покладаюся на себе, пам'ятаю, скопіювавши виконаний SQL-оператор, щоб вставити його у файл update.php. Як тільки ви перейдете на іншу сторінку, я повинен переписати оператор SQL вручну або скасувати зміни та зробити це знову.

Я думаю, що я сподіваюся, що це рішення, яке не вплине на наш усталений робочий процес розвитку?

Автоматизувати. Автоматизувати. Автоматизувати.

Ви на правильному шляху з явним номером версії БД, але я б пішов на крок далі і дав би коду чітко усвідомити, над якою схемою він очікує працювати (наприклад, здійснивши фактичний сценарій DDL та проаналізувавши його оновлення ); то під час оновлення вам потрібно лише виявити існуючу схему за допомогою метаданих бази даних та INSERT / DROP / ALTER за необхідності, незалежно від того, до якої версії до якої версії ви оновлюєтесь. (Ви також можете зберегти явний номер версії в самій базі даних та доставити всю історію схеми з інсталятором, щоб вам навіть не потрібно було відкриття схеми.)

Потенційні помилки синтаксису в сценарії оновлення SQL є проблемою, але ви можете їх вирішити, перевіривши, що оновлення може створювати лише правильні оператори DDL. (Офіційні докази майже ніколи не заслуговують на розробку програмного забезпечення для підприємств - занадто багато зусиль для занадто малої впевненості - але я вважаю, що цілісність бази даних - одне з небагатьох винятків: базовий SQL не є особливо важким мовою для офіційного оволодіння, і користь захист виробничих даних настільки великий, що практично будь-яка кількість одноразових випереджаючих зусиль є виправданою, особливо, якщо вона має працювати для безвідповідних установок,)

Версія схеми бази даних - це саме шлях - кожна версія має лише одну зміну в базі даних або, принаймні, зміни, які можна повернути в цілому. DBDeploy - чудовий інструмент для автоматизації цього.

Деякі речі, які я навчився корисним:

1. Завжди перевіряйте свою зміну на локальному рівні та перевіряйте свій код за допомогою неї, просто ALTERпроходження недостатньо
2. Вам потрібно синхронізувати, хто повинен зробити свою зміну спочатку - проста вікі-сторінка, де ви можете «взяти номер», відмінно працювала для моєї команди.
3. Не намагайтеся виправити порушену зміну, додайте нову зустрічну зміну, щоб її зняти, це набагато безболісніше
4. Ваш код залежить від цих змін - не забудьте пов’язати проблеми у вашій системі відстеження помилок із змінами в БД. Це дуже корисно під час розгортання.
5. Включіть зміни до БД у ваш ІП - застосуйте зміни до бази даних CI під час фіксації. Крім того, якщо у вас є якісь тести, які використовують базу даних, запустіть їх на фіксації.

Оскільки ви використовуєте phpMyAdmin, я припускаю, що ви також використовуєте MySQL.

Погляньте на схеми моделей EER в MySQL Workbench. Вони мені дуже допомогли у підтримці та оновленні схем.

По-перше, ви можете синхронізувати модель з джерелом бази даних. Так що зміни в діаграмі висуваються як команди ALTER TABLE. Це дозволяє виконувати зміни схеми на діаграмі, постійно оновлювати її, а також при необхідності надсилати оновлення до вашої бази розробок.

По-друге, ви можете повернути інженеру схему EER від джерела бази даних. Що може бути корисним шляхом внесення змін у базу даних розробок та оновлення виробничої бази даних, оскільки вона обчислить відмінності.

По-третє, з його допомогою можна створити SQL, який повинен увійти у ваш файл "update.sql".

Мінуси:

Тригери та обмеження бази даних є проблемою із оновленням синхронізації. Здається, не знає правильного порядку речей. Зовнішні ключові обмеження часто генерують помилки, але це можна вирішити, відредагувавши створений SQL.

Це не інструмент міграції даних. Будь-які зміни, що виходять за рамки чистої схеми, все ще потребують користувацького SQL.

Погляньте на http://south.aeracode.org - це бібліотека міграцій БД для Django (рамка Python), але:

1. ви можете отримати від нього чудові ідеї (і, можливо, навіть знайти клон PHP)
2. ви можете фактично використовувати його незалежно від решти Django для керування таблицями програми PHP / MySQL.

Він також може генерувати сценарії оновлення схеми; Крім того, він обробляє зміни реверсу автоматично автоматично більшу частину часу.