Як може змінюватися схема бази даних групових треків?

Які методології управління версіями допомагають командам людей відстежувати зміни схеми бази даних?

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

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

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

вставити в schema_version ( key, extra) значення ('001', 'version schema');

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

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

…

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

Якщо цього не встановлено, RedGate має інструмент для інтеграції керування джерелами в SSMS та SQL Порівняно , корисний для порівняння / синхронізації схем MS SQL Server. У програмі Visual Studio Database Edition також є вбудований інструмент порівняння схем .

Інший SO питання привів мене до Migrator Dot Net , який я збираюся почати розслідування під час мого рясного вільного часу. Це виглядає як хороший метод, але це може бути більше часу / накладних інвестицій, ніж ви готові зробити.

eiefai вже згадується Таблиця, яка повинна існувати у всіх проектах із базою даних . Це чудова публікація в блозі, але IMO - це лише частина шляху до робочого рішення для контролю ревізії бази даних. Я думаю, що будь-яка спроба "відповісти" на це питання в реальному світі потребує врахування деякої іншої інформації про VCS та бази даних:

• Методика Agile Data
• Книга "Рефакторинг баз даних"
• Стаття Мартіна Фаулера про "Еволюційний дизайн баз даних"
• Інструмент Liquibase
• Гідне відео зі Скоттом Амблером, який представляє свої думки про "Agile Databases"

Я думаю, є кілька різних ракурсів підходу до цього питання. Я вважаю, що кут "перший інструмент" змінюватиметься залежно від платформи та особистих переваг. Справа в суті: я використовую проект бази даних в MS Visual Studio, але я не впевнений, що це чудове рішення для MySQL. Я також знаю людей, які продаються на своїх улюблених інструментах від Redgate, Erwin, Embarcadero тощо.

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

Остаточний відповідь на цю тему стане схожим на книгу, тому, мабуть, варто почати з посилання на одну: Redgate нещодавно опублікував безкоштовну електронну книгу під назвою " Керівництво Red Gate для розробки на основі команд SQL Server ", і поки є Є багато де обговорити, це досить гарне місце для початку дискусій, ІМО. Всупереч назві, значна частина матеріалу в цій книзі є достатньо загальною, щоб застосувати до будь-якої БД (не тільки SQL Server) та будь-якого набору інструментів (не лише Redgate). Якщо ви цього ще не бачили, принаймні варто скупити, принаймні.

Нарешті, напевно, варто посилатись на "застарілу відповідь" з stackoverflow .

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

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