Механізми відстеження змін схеми БД [закрито]

Які найкращі методи відстеження та / або автоматизації змін схеми БД? Наша команда використовує Subversion для контролю версій, і нам вдалося автоматизувати деякі наші завдання таким чином (підштовхуючи нарощування до сервісу та встановлення тестування коду на виробничий сервер), але ми все ще робимо оновлення бази даних вручну. Я хотів би знайти або створити рішення, яке дозволяє нам ефективно працювати на серверах з різними середовищами, продовжуючи використовувати Subversion як бекенд, через який оновлення коду та БД передаються на різні сервери.

Багато популярних програмних пакетів включають скрипти автоматичного оновлення, які виявляють версію БД та застосовують необхідні зміни. Це найкращий спосіб зробити це навіть у більшій масштабі (у кількох проектах, а іноді й у багатьох середовищах та мовах)? Якщо так, чи є там якийсь код, який спрощує процес, чи краще просто надати власне рішення? Хтось раніше реалізував щось подібне та інтегрував це в гачки Subversion після завершення чи це погана ідея?

Хоча рішення, яке підтримує декілька платформ, було б кращим, ми, безумовно, повинні підтримувати стек Linux / Apache / MySQL / PHP, оскільки більшість нашої роботи відбувається на цій платформі.

У світі Rails існує концепція міграцій, сценарії, в яких зміни в базі даних вносяться в Ruby, а не до баз даних, характерних для SQL. Ваш міграційний код Ruby в кінцевому підсумку перетворюється в DDL, специфічний для вашої поточної бази даних; це робить комутацію платформ бази даних дуже простою.

За кожну зміну, внесену до бази даних, ви пишете нову міграцію. Міграція, як правило, має два методи: метод "вгору", в якому застосовуються зміни, і метод "вниз", коли зміни не скасовуються. Одна команда приносить базу даних оновленою, а також може бути використана для приведення бази даних до певної версії схеми. У Rails міграції зберігаються у власному каталозі в каталозі проектів і отримують перевірку на контроль версій, як і будь-який інший проектний код.

Цей посібник Oracle щодо міграції рейлів досить добре висвітлює міграцію.

Розробники, що використовують інші мови, розглядали міграції та впровадили власні мовні версії. Я знаю Ruckusing , систему міграцій PHP, яка моделюється після міграції Rails; це може бути те, що ви шукаєте.

Ми використовуємо щось подібне до bcwoord, щоб зберегти наші схеми баз даних синхронізованими через 5 різних установок (виробництво, постановка та декілька інсталяцій розробки), і створили резервну копію в контролі версій, і це працює досить добре. Я детальніше докладу:

Щоб синхронізувати структуру бази даних, у нас є один скрипт, update.php та кількість файлів з номером 1.sql, 2.sql, 3.sql тощо. Сценарій використовує одну додаткову таблицю для зберігання поточного номера версії база даних. Файли N.sql створюються вручну, щоб перейти від версії (N-1) до версії N бази даних.

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

Сценарій оновлення працює так:

• Підключення до бази даних.
• Зробіть резервну копію поточної бази даних (бо матеріал буде йти не так) [туздИшпр].
• Створіть таблицю бухгалтерії (називається _meta), якщо її немає.
• Прочитайте поточну VERSION з таблиці _meta. Припустимо 0, якщо його не знайдено.
• Для всіх .sql-файлів, які мають номер VERSION, виконайте їх у порядку
• Якщо в одному з файлів сталася помилка: поверніться до резервної копії
• В іншому випадку оновіть версію в таблиці бухгалтерського обліку до найвищого .sql-файлу, виконаного.

Все переходить у контроль джерела, і кожна установка має сценарій для оновлення до останньої версії одним виконанням сценарію (виклик update.php з належним паролем бази даних тощо). Ми оновлюємо SVN для постановки та виробничого середовища за допомогою сценарію, який автоматично викликає скрипт оновлення бази даних, тому оновлення коду відбувається з необхідними оновленнями бази даних.

Ми також можемо використовувати той самий сценарій, щоб відтворити всю базу даних з нуля; ми просто скидаємо та відтворюємо базу даних, а потім запускаємо скрипт, який повністю переповнить базу даних. Ми також можемо використовувати сценарій для заповнення порожньої бази даних для автоматизованого тестування.

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

Остерігайтеся, коли вставляєте запити з phpMyAdmin, хоча! Ці згенеровані запити зазвичай містять ім’я бази даних, якого ви точно не хочете, оскільки воно порушить ваші сценарії! Щось на зразок СТВОРИТИ СТОЛ mydb. newtable(...) вийде з ладу, якщо база даних у системі не називається mydb. Ми створили гачок SVN для попереднього коментаря, який забороняє .sql файли, що містять mydbрядок, що є вірним знаком того, що хтось копіює / вставляє з phpMyAdmin без належної перевірки.

Моя команда виписує всі зміни бази даних та передає ці сценарії у SVN разом з кожним випуском програми. Це дозволяє поступово змінювати базу даних, не втрачаючи жодних даних.

Щоб перейти від одного випуску до іншого, вам просто потрібно запустити набір сценаріїв змін, і ваша база даних оновлена, і ви все ще отримали всі свої дані. Це може бути не найпростішим методом, але, безумовно, ефективним.

Проблема тут справді полегшує розробникам сценарій власних локальних змін у контролі джерела, щоб поділитися з командою. Я багато років стикався з цією проблемою і був натхненний функціоналом Visual Studio для професіоналів баз даних. Якщо ви хочете, щоб інструмент з відкритим кодом з тими ж можливостями, спробуйте це: http://dbsourcetools.codeplex.com/ Веселіться, - Натане.

Якщо ви все ще шукаєте рішення: ми пропонуємо інструмент під назвою neXtep дизайнер. Це середовище розробки баз даних, за допомогою якого ви можете поставити всю свою базу даних під контроль версій. Ви працюєте у сховищі з контрольованою версією, де можна відстежувати кожну зміну.

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

Тоді у вас є багато варіантів: ви можете взяти ці сценарії та помістити їх у свій SVN з кодом програми, щоб він був розгорнутий наявним механізмом. Інший варіант полягає у використанні механізму доставки neXtep: сценарії експортуються у щось, що називається "пакет доставки" (SQL скрипти + дескриптор XML), і інсталятор може зрозуміти цей пакет і розгорнути його на цільовому сервері, забезпечуючи послідовність стриктури, залежність перевірка, реєстрація встановленої версії тощо.

Продукт є GPL та заснований на Eclipse, тому він працює на Linux, Mac та Windows. Наразі він також підтримує Oracle, Mysql та Postgresql (дорога підтримка DB2). Погляньте на вікі, де ви знайдете більш детальну інформацію: http://www.nextep-softwares.com/wiki

Скотт Амблер випускає велику серію статей (і є співавтором книги ) про рефакторинг баз даних, з ідеєю, що ви, по суті, повинні застосовувати принципи та практики TDD для підтримки вашої схеми. Ви встановили серію тестів структури та насіннєвих даних для бази даних. Потім, перш ніж щось змінити, ви модифікуєте / пишете тести, щоб відобразити цю зміну.

Ми робимо це вже деякий час і, здається, працює. Ми написали код для генерації базових імен стовпців і перевірки типу даних в наборі тестування блоків. Ми можемо повторно застосувати ці тести, щоб переконатися, що база даних у касі SVN відповідає реальним db, які програма працює насправді.

Як виявляється, розробники також інколи налаштовують свою базу даних пісочниці і нехтують оновленням файлу схеми в SVN. Код тоді залежить від зміни ДБ, яка не була зареєстрована. Таку помилку неможливо важко виправити, але тестовий набір підбере її відразу. Це особливо приємно, якщо ви його вбудували у більший план постійної інтеграції.

Скиньте схему у файл та додайте її до керування джерелом. Тоді простий розмін покаже вам, що змінилося.

К. Скотт Аллен має гідну статтю або дві статті про версію схеми, яка використовує схеми покрокових оновлень сценаріїв / міграцій, на які йдеться в інших відповідях тут; див. http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

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

Потім зафіксуйте скрипт у керуванні джерелом разом із кодом, який працює на ньому. Коли вам потрібно змінити схему разом з кодом, скрипт можна зареєструвати разом з кодом, який вимагає зміненої схеми. Тоді, diff на скрипті буде вказувати, що відрізняється від змін схеми.

За допомогою цього сценарію ви можете інтегрувати його з DBUnit або яким-небудь сценарієм збірки, тому, здається, він міг би відповідати вашим уже автоматизованим процесам.

Якщо ви використовуєте C #, перегляньте Subsonic, дуже корисний інструмент ORM, але також генерує скрипт sql для відтворення вашої схеми та \ або даних. Ці сценарії потім можуть бути передані в управління джерелами.

http://subsonicproject.com/

Я використовував таку структуру проекту бази даних у Visual Studio для декількох проектів, і це спрацювало досить добре:

База даних

Зміна сценаріїв

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Створюйте сценарії

Спроки

Функції

Перегляди

Потім наша система збирання оновлює базу даних від однієї версії до наступної, виконуючи сценарії в наступному порядку:

1.PreDeploy.sql

2.SchemaChanges.sql

Зміст папки Створення скриптів

2.DataChanges.sql

3.Permissions.sql

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

Ми використовуємо дуже просте, але при цьому ефективне рішення.

Для нових встановлень у нас є файл metadata.sql у сховищі, де зберігаються всі схеми БД, тоді в процесі збирання ми використовуємо цей файл для створення бази даних.

Для оновлень ми додаємо оновлення в програмне забезпечення з жорстким кодом. Ми тримаємо це в кодовому коді, тому що нам не подобається вирішувати проблеми, перш ніж це справді є проблемою, і подібні речі поки що не виявилися проблемами.

Тож у нашому програмному забезпеченні є щось подібне:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Цей код перевірить, чи є база даних у версії 1 (яка зберігається в таблиці, створеній автоматично), якщо вона застаріла, тоді команда виконується.

Для оновлення метаданих.sql у сховищі ми запускаємо це оновлення локально, а потім витягуємо цілі метадані бази даних.

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

Крім того, ми не підтримуємо оновлення версій, але це, за дизайном, якщо в оновленнях щось не вдається, ми відновили попередню версію та виправили оновлення перед повторною спробою.

Я створюю папки, названі на честь версій збірки, і розміщую там сценарії оновлення та поновлення. Наприклад, у вас можуть бути такі папки: 1.0.0, 1.0.1 та 1.0.2. Кожен містить скрипт, що дозволяє оновити або понизити вашу базу даних між версіями.

Якщо клієнт або клієнт подзвонить вам із проблемою версії 1.0.1, а ви використовуєте 1.0.2, повернення бази даних до його версії не буде проблемою.

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

Як Джої сказав, якщо ви перебуваєте у світі Рейлів, використовуйте міграцію. :)

Для мого поточного проекту PHP ми використовуємо ідею міграції рейок, і у нас є каталог міграцій, в якому ми зберігаємо заголовок файлів "migra_XX.sql", де XX - номер міграції. В даний час ці файли створюються вручну по мірі оновлення, але їх створення можна легко змінити.

Тоді у нас є сценарій під назвою "Migration_watcher", який, як і в попередній альфа, наразі працює на кожному завантаженні сторінки і перевіряє, чи є новий файл migra_XX.sql, де XX більше, ніж поточна версія міграції. Якщо так, він запускає всі файли migra_XX.sql до найбільшої кількості проти бази даних та вуаля! зміни схеми автоматизовані.

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

Я рекомендую використовувати Ant (крос-платформу) для "сценаріїв" сторони (оскільки вона може практично спілкуватися з будь-яким db там через jdbc) та Subversion для вихідного сховища. Мураха дозволить вам "створити резервну копію" вашого db до локальних файлів, перш ніж вносити зміни. 1. створити резервну копію існуючої схеми db для файлу через Ant 2. контроль версій у сховище Subversion через Ant 3. надсилає нові заяви sql до db через Ant

Toad для MySQL має функцію під назвою схема порівняння, яка дозволяє синхронізувати 2 бази даних. Це найкращий інструмент, який я використовував досі.

Мені подобається, як Yii обробляє міграцію бази даних. Міграція - це в основному сценарій PHP CDbMigration. CDbMigrationвизначає upметод, який містить логіку міграції. Можливо також реалізувати downметод підтримки зворотної міграції. Альтернативно, safeUpабо safeDownможе бути використаний для переконання, що міграція проводиться в контексті транзакції.

Інструмент командного рядка Yii yiicмістить підтримку для створення та виконання міграцій. Міграції можуть бути застосовані або повернені по одній або в партії. Створення результатів міграції в коді для реалізації класу PHPCDbMigration , однозначно названий на основі часової позначки та імені міграції, визначеного користувачем. Усі міграції, які раніше були застосовані до бази даних, зберігаються в таблиці міграції.

Для отримання додаткової інформації дивіться статтю з міграції баз даних у посібнику.

Спробуйте db-розгортання - головним чином інструмент Java, але працює і з php.

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

Міграція ІМХО має величезну проблему:

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

Запуск усієї історії дельт від базової лінії до поточної версії (для сотень баз даних клієнтів) може зайняти дуже багато часу.

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