Чи існує система управління версіями для зміни структури бази даних?

Я часто стикаюся з такою проблемою.

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

Отже, я натискаю на живу систему і отримую велику, очевидну помилку, що її немає NewColumnX, так.

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

У Ruby on Rails існує концепція міграції - швидкий сценарій для зміни бази даних.

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

Щоб перемістити вгору , ви запускаєте команду під назвою "db: migrate", яка переглядає вашу версію і застосовує необхідні сценарії. Ви можете мігрувати вниз аналогічним чином.

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

Я трохи старий, тому що я використовую вихідні файли для створення бази даних. Насправді є два файли - project-database.sql та project-updates.sql - перший для схеми та постійних даних, а другий для модифікацій. Звичайно, обидва знаходяться під контролем джерела.

Коли база даних змінюється, я спочатку оновлюю основну схему в project-database.sql, після чого копіюю відповідну інформацію в project-updates.sql, наприклад, ALTER TABLE. Потім я можу застосувати оновлення до бази розробок, тестувати, повторювати, поки не буде зроблено добре. Потім перевірте файли, протестуйте ще раз і застосуйте до виробництва.

Крім того, у мене зазвичай є таблиця в db - Config - наприклад:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Потім я додаю наступне до розділу оновлення:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Змінюється db_versionлише тоді, коли база даних відтворена, і db_revisionдає мені вказівку, наскільки db знаходиться від базової лінії.

Я міг би зберігати оновлення у власних окремих файлах, але я вирішив їх перемішувати разом і використовувати cut & paste для вилучення відповідних розділів. Трохи більше ведеться ведення господарства, тобто видаліть ':' з $ Revision 1.1 $, щоб заморозити їх.

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

Для досягнення належної практики управління зміною бази даних нам потрібно визначити кілька ключових цілей. Таким чином, міграційна система MyBatis Schema (або коротка міграція MyBatis) прагне:

• Працюйте з будь-якою базою даних, новою чи вже наявною
• Використовуйте систему управління джерелом (наприклад, Subversion)
• Увімкніть одночасних розробників або команди працювати самостійно
• Дозвольте конфлікти дуже помітні та легко керовані
• Дозволити міграцію вперед і назад (еволюціонувати, переходити відповідно)
• Зробіть поточний стан бази даних легкодоступним і зрозумілим
• Увімкніть міграцію, незважаючи на привілеї доступу чи бюрократію
• Робота з будь-якою методологією
• Заохочує добрі, послідовні практики

Redgate має продукт, який називається SQL Source Control . Він інтегрується з TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce та Git.

Дуже рекомендую дельта SQL . Я просто використовую його для створення різних сценаріїв, коли я закінчую кодування моєї функції та перевіряю ці сценарії в своєму інструменті управління джерелами (Mercurial :))

Вони мають як SQL-сервер, так і версію Oracle.

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

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Тож вам не потрібно цим займатися самостійно

Чисті заяви sql або імпорт даних також підтримуються.

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

Якщо ви використовуєте SQL Server, важко перемогти Data Dude (він же - версія бази даних Visual Studio). Після того, як ви отримаєте вивірку, порівняння схеми між вашою контрольованою джерелом версією бази даних та версією у виробництві стане легким. І одним клацанням миші ви можете генерувати свій різний DDL.

На MSDN є навчальне відео, яке дуже корисно.

Я знаю про DBMS_METADATA та Toad, але якби хтось міг придумати Data Dude for Oracle, життя було б справді приємним.

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

Найскладніша частина, яку я бачу, - це відстеження залежностей, наприклад, для певної таблиці розгортання B, можливо, потрібно буде оновити перед таблицею А.

Для Oracle я використовую Toad , який може скидати схему до декількох дискретних файлів (наприклад, один файл у таблиці). У мене є кілька сценаріїв, які керують цією колекцією в Perforce, але я думаю, що це повинно бути легко виконаним практично в будь-якій системі контролю версій.

Погляньте на пакет Oracle DBMS_METADATA.

Зокрема, такі методи особливо корисні:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Після ознайомлення з тим, як вони працюють (досить зрозуміло), ви можете написати простий скрипт, щоб перенести результати цих методів у текстові файли, які можна поставити під контроль джерела. Удачі!

Не впевнений, чи є щось таке просте для MSSQL.

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

Я робив це заздалегідь - керуючи (або намагаючись керувати) версіями схем. Найкращі підходи залежать від ваших інструментів. Якщо ви можете отримати інструмент програмного забезпечення Quest "Schema Manager", ви будете в хорошій формі. У Oracle є власний, неповноцінний інструмент, який також називають "Schema Manager" (багато що бентежить?), Який я не рекомендую.

Без автоматизованого інструменту (див. Інші коментарі тут про Data Dude), тоді ви будете використовувати сценарії та файли DDL безпосередньо. Виберіть підхід, документуйте його і суворо дотримуйтесь його. Мені подобається можливість в будь-який момент знову створити базу даних, тому я віддаю перевагу повний експорт DDL всієї бази даних (якщо я DBA) або схеми розробника (якщо я в продукті -режим розвитку).

PLSQL Developer, інструмент від All Arround Automations, має плагін для сховищ, який працює добре (але не чудово) з Visual Source Safe.

З Інтернету:

Плагін Control Control забезпечує тісну інтеграцію між PLE / SQL Developer IDE >> та будь-якою системою управління версіями, яка підтримує специфікацію інтерфейсу Microsoft SCC. >> Сюди входять найпопулярніші системи управління версіями, такі як Microsoft Visual SourceSafe, >> Merant PVCS та MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio дозволяє повернути схему бази даних в інструмент, а потім можна порівняти її з живими базами даних.

Приклад: Поверніть схему розробки в ER Studio - порівняйте її з виробництвом, і вона перелічить усі відмінності. Він може скриптувати зміни або просто автоматично просувати їх.

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

Існує PHP5 "міграція бази даних" під назвою Ruckusing. Я не використовував його, але приклади показують ідею, якщо ви використовуєте мову для створення бази даних як і коли потрібно, вам потрібно лише відстежувати вихідні файли.

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

Ми використовували MS Team System Database Edition з досить хорошим успіхом. Він інтегрується з контролем версій TFS та Visual Studio більш-менш легко і дозволяє нам легко керувати збереженими документами, переглядами тощо. Вирішення конфліктів може бути болем, але історія версій завершена, як тільки це буде зроблено. Після цього міграція до забезпечення якості та виробництва надзвичайно проста.

Справедливо сказати, що це продукт версії 1.0, однак, і це не обходиться без кількох питань.

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

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

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

Я б рекомендував один із двох підходів. По-перше, інвестуйте в PowerDesigner від Sybase. Enterprise Edition. Це дозволяє проектувати фізичні моделі даних та ще багато іншого. Але він постачається з сховищем, яке дозволяє перевірити свої моделі. Кожна нова реєстрація може бути новою версією, вона може порівнювати будь-яку версію з будь-якою іншою версією і навіть з тією, що є у вашій базі даних на той час. Потім він представить список кожної різниці і запитає, яку слід перенести…, а потім створить сценарій для цього. Це не дешево, але це вигідна удвічі більша ціна, а рентабельність інвестицій становить близько 6 місяців.

Інша ідея - включити аудит DDL (працює в Oracle). Це створить таблицю з кожною внесеною вами зміною. Якщо ви запитаєте зміни від часової позначки, в яку ви востаннє перемістили зміни вашої бази даних, щоб продати зараз, до потрібного, у вас буде впорядкований список всього, що ви зробили. Кілька, де застереження про усунення змін із нульовою сумою, як, наприклад, створення foo table; слідом за столом падіння столу; і ви можете ЛЕГКО побудувати модний скрипт. Навіщо тримати зміни у вікі, це подвійна робота. Нехай база даних відстежує їх для вас.

Дві книжкові рекомендації: "Рефакторинг баз даних" Ambler та Sadalage та "Agile Database Techniques" від Ambler.

Хтось згадав міграцію рейлів. Я думаю, що вони чудово працюють навіть поза програмами Rails. Я використовував їх у програмі ASP із SQL Server, який ми переходили до Rails. Ви перевіряєте самі сценарії міграції у VCS. Ось пост прагматичного Дейва Томаса на цю тему.