Я хочу отримати свої бази даних під контролем версій. Хтось має поради або рекомендації, щоб почати мене?

Я завжди хочу мати хоч якісь дані там (як згадує alumb : типи користувачів та адміністратори). Я також часто хочу велику колекцію згенерованих тестових даних для вимірювань продуктивності.

Мартін Фаулер написав мою улюблену статтю на цю тему, http://martinfowler.com/articles/evodb.html . Я вирішу не вводити дамп схеми під контроль версій як alumb та інші пропонують, тому що я хочу простий спосіб оновити свою виробничу базу даних.

Для веб-програми, де у мене буде один примірник виробничої бази, я використовую дві методики:

Сценарії оновлення бази даних

Сценарії оновлення бази даних послідовностей, що містять DDL, необхідний для переміщення схеми з версії N до N + 1. (Вони входять у вашу систему управління версіями.) Таблиця _version_history_, щось подібне

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

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

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

Синхронізація пісочниці розробника

1. Сценарій для резервного копіювання, очищення та зменшення виробничої бази даних. Виконайте це після кожного оновлення до виробничої БД.
2. Сценарій для відновлення (і підстроювання, якщо необхідно) резервної копії на робочій станції розробника. Кожен розробник запускає цей сценарій після кожного оновлення до виробничої БД.

Застереження: мої автоматизовані тести працюють проти правильної схеми, але порожньої бази даних, тому ця порада не буде ідеально відповідати вашим потребам.

Продукт порівняння SQL Red Gate не тільки дозволяє проводити порівняння на рівні об'єктів і генерувати сценарії змін із цього, але також дозволяє експортувати об’єкти бази даних в ієрархію папок, організовану за типом об'єкта, з одним створенням [objectname] .sql скрипт на об'єкт у цих каталогах. Ієрархія типу об'єкта виглядає так:

\ Функції
\ Безпека
\ Безпека \ Ролі
\ Безпека \ Схеми
\ Безпека \ Користувачі
\ Збережені процедури
\ Таблиці

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

Це одна з "важких проблем" навколо розвитку. Наскільки я знаю, ідеальних рішень немає.

Якщо вам потрібно зберігати лише структуру бази даних, а не дані, ви можете експортувати базу даних у вигляді SQL-запитів. (у Enterprise Manager: Клацніть правою кнопкою миші на базі даних -> Створити скрипт SQL. Я рекомендую встановити "створити один файл на об'єкт" на вкладці параметрів) Потім ви можете зафіксувати ці текстові файли у svn та використати функції diff та журналу svn.

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

Якщо вам також потрібно зберегти всі дані, я рекомендую зберігати резервну копію бази даних та використовувати продукти Redgate ( http://www.red-gate.com/ ) для порівняння. Вони не дешеві, але коштують кожної копійки.

По-перше, ви повинні вибрати систему контролю версій, яка підходить саме вам:

• Централізована система управління версіями - стандартна система, де користувачі перевіряють / перевіряють до / після роботи над файлами, а файли зберігаються на одному центральному сервері

• Розподілена система управління версіями - система, в якій клонується репозиторій, і кожен клон - це фактично повна резервна копія сховища, тому якщо якийсь сервер виходить з ладу, то будь-який клонований сховище може бути використаний для його відновлення Після вибору потрібної системи для ваших потреб вам знадобиться налаштувати сховище, яке є ядром кожної системи управління версіями. Все це пояснено в наступній статті: http://solutioncenter.apexsql.com/sql-server-source-control-part-i- розуміння основи управління ресурсами /

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

• Студія управління SQL Server через постачальника MSSCCI,

• Інструменти даних Visual Studio та SQL Server

• Сторонній інструмент ApexSQL Source Control

Тут у Red Gate ми пропонуємо інструмент, SQL Source Control , який використовує технологію SQL Compare для зв’язку вашої бази даних із сховищем TFS або SVN. Цей інструмент інтегрується в SSMS і дозволяє вам працювати, як зазвичай, за винятком випадків, коли він дозволяє здійснювати об'єкти.

Для підходу на основі міграцій (більше підходить для автоматизованих розгортань) ми пропонуємо автоматизацію змін SQL (раніше називалася ReadyRoll), яка створює та керує набором додаткових сценаріїв як проект Visual Studio.

У SQL Source Control можна вказати статичні таблиці даних. Вони зберігаються в керуванні джерелами як заяви INSERT.

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

Ви можете подивитися на Liquibase ( http://www.liquibase.org/ ). Навіть якщо ви не використовуєте сам інструмент, він досить добре обробляє концепції управління змінами бази даних або рефакторинг.

+1 для всіх, хто рекомендував інструменти RedGate, з додатковою рекомендацією та застереженням.

SqlCompare також має пристойно задокументований API: ви можете, наприклад, написати консольний додаток, який синхронізує папку сценаріїв, керованих джерелом, з базою даних тестування інтеграції CI під час реєстрації, щоб коли хтось перевіряв зміну схеми зі своєї папки сценаріїв він автоматично розгортається разом зі зміною відповідного коду програми. Це допомагає усунути розрив із розробниками, які забувають про поширення змін у своєму локальному DB до загальної БД розробки (я думаю, що близько половини з нас).

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

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

З VS 2010 використовуйте проект Database.

1. Сценарій вашої бази даних
2. Внесіть зміни в сценарії або безпосередньо на db-сервер
3. Синхронізуйте за допомогою даних> Порівняння схем

Здійснює ідеальне рішення для версії БД і робить синхронізацію БД легким вітром.

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

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

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

Ви також можете подивитися на питання міграції. Вони дозволяють вказати схему вашої бази даних у коді C # та прокрутити версію бази даних вгору та вниз за допомогою MSBuild.

Зараз я використовую DbUp , і він працює добре.

Ви не згадали жодних особливостей щодо вашого цільового середовища чи обмежень, тому це може бути не цілком застосовно ... але якщо ви шукаєте спосіб ефективного відстеження що розвивається схеми БД і не заважають ідеї використання Міграції Ruby, ActiveRecord - це прямо ваша алея.

Міграції програмно визначають перетворення бази даних за допомогою Ruby DSL; кожне перетворення можна застосувати або (як правило) відкотити назад, що дозволяє перейти до іншої версії вашої схеми БД у будь-який момент часу. Файл, що визначає ці перетворення, можна перевірити в контролі версій, як і будь-який інший фрагмент вихідного коду.

Оскільки міграції є частиною ActiveRecord , вони, як правило, знаходять застосування в повнорозмірних програмах Rails; однак ви можете використовувати ActiveRecord незалежно від Rails з мінімальними зусиллями. Дивіться тут для більш детального лікування використання міграції AR за межами Rails.

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

Це просто.

1. Коли базовий проект буде готовий, ви повинні створити повний сценарій бази даних. Цей скрипт доручено SVN. Це перша версія.

2. Після цього всі розробники створюють сценарії змін (ALTER ..., нові таблиці, проростки тощо).

3. Коли вам потрібна поточна версія, тоді слід виконати всі нові сценарії змін.

4. Коли додаток випущено у виробництво, ви повернетесь до 1 (але тоді це буде, звичайно, версія).

Nant допоможе вам виконати ці сценарії зміни. :)

І пам’ятайте. Все працює добре, коли є дисципліна. Кожен раз, коли відбувається зміна бази даних, тоді також здійснюються відповідні функції в коді.

Якщо у вас є невелика база даних, і ви хочете опублікувати всю версію, цей пакетний сценарій може допомогти. Він відокремлює, стискає та перевіряє файл MDF бази даних MSSQL у Subversion.

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

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

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

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Нормальний режим роботи: Ви можете взяти результати з цього sql та генерувати сценарії sql лише для тих, що вас цікавлять, і поставити їх у джерело керування на ваш вибір.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Примітка. Якщо ви використовуєте нестандартне порівняння в будь-якій зі своїх баз даних, вам потрібно буде замінити /* COLLATE */їх зіставленням у базі даних. тобтоCOLLATE Latin1_General_CI_AI

Оскільки наша програма повинна працювати в декількох RDBMS, ми зберігаємо наше визначення схеми в контролі версій, використовуючи нейтральний для бази даних формат Torque (XML). Також ми контролюємо версії довідкових даних для нашої бази даних у форматі XML наступним чином (де "Зв'язок" - одна з довідкових таблиць):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Потім ми використовуємо інструменти для вирощування в домашніх умовах, щоб генерувати схеми оновлення схеми та сценарії оновлення довідкових даних, необхідні для переходу від версії X бази даних до версії X + 1.

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

Після переходу на платформу x64 у нас виникла потреба у версії нашої бази даних SQL, і наша стара версія перервалася з міграцією. Ми написали додаток C #, яке використовувало SQLDMO для відображення всіх об'єктів SQL у папку:

                Корінь
                    Ім'я сервера
                       Ім'я бази даних
                          Об'єкти схеми
                             Тригери бази даних *
                                .ddltrigger.sql
                             Функції
                                ..функція.sql
                             Безпека
                                Ролі
                                   Ролі застосування
                                      .approle.sql
                                   Ролі бази даних
                                      .role.sql
                                Схеми *
                                   .schema.sql
                                Користувачі
                                   .user.sql
                             Зберігання
                                Повні текстові каталоги *
                                   .fulltext.sql
                             Збережені процедури
                                ..proc.sql
                             Синоніми *
                                .synonym.sql
                             Столи
                                .. таблиця.sql
                                Обмеження
                                   ... chkconst.sql
                                   ... defconst.sql
                                Покажчики
                                   ... index.sql
                                Ключі
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Тригери
                                   ... тригер.sql
                             Типи
                                Типи даних, визначені користувачем
                                   ..uddt.sql
                                Колекції схем XML *
                                   ..xmlschema.sql
                             Перегляди
                                ..view.sql
                                Покажчики
                                   ... index.sql
                                Тригери
                                   ... тригер.sql

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

Я писав цю програму деякий час тому, http://sqlschemasourcectrl.codeplex.com/, яка скануватиме ваші MSFT SQL db так часто, як вам потрібно, і автоматично скидає ваші об'єкти (таблиці, представлення даних, програми, функції, настройки sql) у SVN. Працює як шарм. Я використовую його з Unfuddle (що дозволяє отримувати сповіщення про реєстрацію)

Типовим рішенням є скидання бази даних за необхідності та резервне копіювання цих файлів.

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

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

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

Але ця модель не дуже добре підходить до великих або сторонніх баз даних (які шифрують об'єкти). Отже, що ми зробили - це зберігати лише наші спеціалізовані об’єкти. Для цього дуже добре працює сервер фундаментів Visual Studio / Team.

Головний арк бази даних TFS блог

Сайт MS TFS

Я погоджуюся з відповіддю ESV, і саме тому я почав трохи проектувати назад, щоб допомогти підтримувати оновлення бази даних у дуже простому файлі, який потім міг би підтримувати довгий вихідний код. Це дозволяє легко оновлювати розробників, а також UAT та Production. Інструмент працює на серверах Sql та MySql.

Деякі функції проекту:

• Дозволяє зміни схеми
• Дозволяє оцінити популяцію дерев
• Дозволяє роздільні вставки для тестових даних, наприклад, УАТ
• Дозволяє варіант відката (не автоматизований)
• Підтримує підтримку SQL-сервера та Mysql
• Має можливість імпортувати наявну базу даних до контролю версій за допомогою однієї простої команди (лише сервер sql ... все ще працює над mysql)

Код розміщений на коді google. Будь ласка, ознайомтеся з кодом Google для отримання додаткової інформації

http://code.google.com/p/databaseversioncontrol/

Нещодавно я знайшов базовий модуль VB, який використовував об'єкти DMO та VSS, щоб отримати цілий db сценарій і перейти у VSS. Я перетворив його на сценарій VB і розмістив його тут . Ви можете легко здійснити виклики VSS та використовувати вміст DMO для створення всіх сценаріїв, а потім викликати SVN з того самого пакетного файлу, який викликає VBScript, щоб перевірити їх?

Дейв Дж

Я також використовую версію в базі даних, що зберігається за допомогою розширеної групи властивостей баз даних. У моїй програмі є сценарії для кожного кроку версії (тобто перехід від 1,1 до 1,2). Під час розгортання він переглядає поточну версію, а потім запускає сценарії по черзі, поки не досягне останньої версії програми. Немає сценарію, який має пряму "остаточну" версію, навіть розгортання в чистому БД виконує розгортання через ряд кроків оновлення.

Тепер мені подобається те, що я два дні тому бачив презентацію в кампусі MS про нову та майбутню версію VS DB. Презентація була зосереджена саме на цій темі, і мене вирвало з води. Ви обов'язково повинні це перевірити, нові засоби орієнтовані на збереження визначення схеми в T-SQL-скриптах (CREATEs), дельта-механізм виконання, щоб порівняти схему розгортання з визначеною схемою та робити дельта ALTERs та інтеграцію з інтеграцією вихідного коду, аж до включаючи безперервну інтеграцію MSBUILD для автоматизованих крапель збірки. Падіння містить новий тип файлу, файли .dbschema, які можна перенести на сайт розгортання, а інструмент командного рядка може зробити фактичні «дельти» та запустити розгортання. У мене є запис у цьому блозі із посиланнями на завантаження VSDE, ви повинні перевірити їх:http://rusanu.com/2009/05/15/version-control-and-your-database/

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

На мій досвід, рішення двояке:

1. Вам потрібно обробити зміни в базі даних розробок, які робляться декількома розробниками під час розробки.

2. Вам потрібно обробити оновлення бази даних на сайтах клієнтів.

Для обробки №1 вам знадобиться потужний інструмент розробки / злиття бази даних. Найкращий інструмент повинен мати можливість виконувати автоматичне злиття якнайбільше, дозволяючи вирішувати незроблені конфлікти вручну.

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

Я написав комерційний інструмент, який надає підтримку вручну злиття баз даних SQLite, і в даний час я додаю підтримку тривимірного алгоритму об'єднання для SQLite. Перевірте це за адресою http://www.sqlitecompare.com

Для обробки №2 вам знадобиться система оновлення.

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

Перегляньте мою статтю з цього приводу в http://www.codeproject.com/KB/database/sqlite_upgrade.aspx, щоб отримати загальне уявлення про те, про що я говорю.

Щасти

Лірон Леві

Перевірте DBGhost http://www.innovartis.co.uk/ . Я використовую в автоматизованому режимі вже 2 роки, і це чудово працює. Це дозволяє нам складати БД так, як відбувається збірка Java або C, за винятком бази даних. Ти знаєш, що я маю на увазі.

Я б запропонував використовувати інструменти порівняння для імпровізації системи контролю версій для вашої бази даних. Хорошою альтернативою є порівняння схем xSQL та порівняння даних xSQL .

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

На жаль, якщо ви хочете також мати дані під контролем версій, ви можете використовувати xSQL Data Порівняння для створення скриптів змін для вашої бази даних та додавання .sql файлів у контролі версій. Потім ви можете виконати ці сценарії для відновлення / оновлення до будь-якої потрібної вам версії. Майте на увазі, що для функцій "повернення" вам потрібно генерувати сценарії змін, які при виконанні будуть робити версію 3 такою ж, як і версію 2, а для функцій "оновлення" вам потрібно створити сценарії змін, які роблять навпаки.

Нарешті, за допомогою деяких базових навичок пакетного програмування ви можете автоматизувати весь процес, використовуючи версії командного рядка xSQL Schema Порівняння та xSQL Data Порівняння

Відмова: Я приєднався до xSQL.