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

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

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

Мені потрібно бути впевненим, оскільки ці зміни не є сумісними назад; Я не можу дозволити собі накрутити.

База даних у моєму випадку - PostgreSQL

Редагувати:

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

Має бути кращий спосіб.

Оновлення:

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

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

Чи буде sqlite зручним для git?

Оскільки це лише середовище розробки, я можу вибрати будь-яку базу даних.

Edit2:

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

Натомість візьміть дамп бази даних та керуйте версіями. Таким чином це плоский текстовий файл.

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

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

Ознайомтеся з базами даних Refactoring ( http://databaserefactoring.com/ ), щоб отримати купу хороших методик для підтримки вашої бази даних у тандемі зі змінами коду.

Досить сказати, що ви задаєте неправильні запитання. Замість того, щоб ставити базу даних в git, вам слід розкласти свої зміни на невеликі перевірені кроки, щоб ви могли легко мігрувати / відмовляти зміни схеми.

Якщо ви хочете отримати повну відновлюваність, вам слід розглянути питання архівації ваших журналів WAL postgres та використати PITR (відновлення моменту часу) для відтворення транзакцій назад / переадресації до конкретних відомих хороших станів.

Я починаю думати про дуже просте рішення, не знаю, чому я не думав про це раніше !!

• Дублювати базу даних (і схему, і дані).
• У відділенні для нових-основних змін просто змініть конфігурацію проекту, щоб використовувати нову копію бази даних.

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

Редагувати:

Під дублікатами я маю на увазі створення іншої бази даних з іншим ім’ям (як my_db_2); не роблячи сміття чи нічого подібного.

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

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

1. Sqitch - відкритий код на основі perl; доступний для всіх основних баз даних, включаючи PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - лише для PostgreSQL; керування версіями схеми бази даних з відкритим кодом. https://github.com/cbbrowne/mahout
3. Liquibase - ще одне відкрите джерело керування версіями db sw. безкоштовна версія Datical. http://www.liquibase.org/index.html
4. Datical - комерційна версія Liquibase - https://www.datical.com/
5. Flyway від BoxFuse - комерційний sw. https://flywaydb.org/
6. Інший проект з відкритим кодом https://gitlab.com/depesz/Versioning Автор надає посібник тут: https://www.depesz.com/2010/08/22/versioning/
7. Автоматизація змін червоних воріт - лише для SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation/

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

Його досі в альфа-стані та створено для php.

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

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

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

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

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

Якщо ви хочете керувати змінами, у вашій базі даних є дві дискретні проблеми, і я би вирішував їх окремо (якби я був на вашій увазі). Перше - це схема, друге - дані (хоча у вашому запитанні ви заявляєте дані - це не те, що вас хвилює). Проблемою, яка була в мене раніше, була база даних Dev and Prod, де Dev міг робити додаткові зміни в схемі, і ці зміни повинні бути задокументовані в CVS та запропоновані до проживання разом із доповненнями до одного з кількох "статичних" столи. Ми зробили це, маючи 3-ту базу даних під назвою Cruise, яка містила лише статичні дані. У будь-який момент можна порівняти схему від Dev і Cruise, і у нас був сценарій, щоб взяти diff цих 2 файлів і створити файл SQL, що містить ALTER заяви, щоб застосувати його. Аналогічно будь-які нові дані, можна перегнати у файл SQL, що містить команди INSERT. Поки поля та таблиці тільки додаються і ніколи не видаляються, процес може автоматизувати генерацію операторів SQL для застосування дельти.

Механізм, за допомогою якого git генерує дельти, diffі механізм, за допомогою якого він поєднує 1 або більше дельт з файлом, називається merge. Якщо ви можете придумати метод розрізнення та злиття з іншого контексту, git повинен працювати, але, як уже говорилося, ви можете віддати перевагу інструменту, який робить це для вас. Моя перша думка щодо вирішення цього питання - це https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools, в якому детально описано, як замінити внутрішній розріз Git та інструмент злиття. Я оновлю цю відповідь, оскільки придумаю краще вирішення проблеми, але в моєму випадку я очікую, що мені доведеться керувати лише змінами даних, так як поки що файловий магазин на базі БД може змінитися, тому моє рішення може не бути саме тим, що вам потрібно.

Погляньте на RedGate SQL Source Control.

http://www.red-gate.com/products/sql-development/sql-source-control/

Цей інструмент являє собою оснащення програми SQL Server Management Studio, яка дозволить вам розмістити свою базу даних під управлінням Source та Git.

Це трохи дорого - 495 доларів за кожного користувача, але є 28-денна безкоштовна пробна версія.

ПРИМІТКА. Я жодним чином не пов'язаний з RedGate.

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

Я буду дотримуватися ідей у ​​цьому дописі від Володимира Хорікова "Найкращі практики версій бази даних" . Підсумовуючи, я буду

• зберігати як його схему, так і довідкові дані в системі управління джерелом.
• для кожної модифікації ми створимо окремий скрипт SQL із змінами

У випадку, якщо це допоможе!

• Ірмін
• Flur.ee
• Crux DB

Я деякий час шукав ту саму функцію для Postgres (або взагалі баз даних SQL), але не знайшов інструментів, які були б достатньо підходящими (простими та інтуїтивно зрозумілими). Ймовірно, це пов'язано з бінарним характером того, як зберігаються дані. Клоніо звучить ідеально, але виглядає мертвим. Noms DB виглядає цікаво ( і живим ). Також погляньте на Irmin (на базі OCaml з властивостями Git).

Хоча це не відповідає на питання про те, що він би працював з Postgres, перегляньте базу даних Flur.ee. Він має функцію "подорож за часом", яка дозволяє запитувати дані з довільного моменту часу. Я здогадуюсь, він повинен мати можливість працювати з "розгалужуючою" моделлю.

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

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

Оновлення : також перегляньте базу даних Crux , яка може запитувати через часовий вимір вставок, який ви можете бачити як "версії". Crux, здається, є реалізацією з відкритим кодом високо оціненої Datomic.

Crux - це бітмопоральна база даних, яка зберігає час транзакцій та дійсні історії часу. У той час як тимчасова база даних [uni] дозволяє запитувати "подорож у часі" через транзакційну послідовність станів бази даних з моменту створення бази даних до її поточного стану, Crux також забезпечує запит "подорожі в часі" для дискретної дійсної осі часу без зайвої складності проектування або ефективність. Це означає, що користувач Crux може заповнювати базу даних минулою та майбутньою інформацією незалежно від порядку, в якому інформація надходить, і вносити виправлення в минулі записи для побудови постійно вдосконалюваної часової моделі даного домену.

Ви не можете зробити це без атомності, і ви не можете отримати атомність, не використовуючи ні pg_dump, ні файлову систему.

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

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

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

Я випустив інструмент для sqlite, який робить те, що ви просите. Він використовує спеціальний драйвер diff, використовуючи інструмент sqlite проектів 'sqldiff', UUID в якості первинних ключів, і не залишає sqlite rowid. Він все ще знаходиться в альфа, тому відгуки високо оцінені.

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

https://github.com/cannadayr/git-sqlite

Я думаю, що X-Istence на правильному шляху, але є ще кілька вдосконалень, які ви можете внести до цієї стратегії. Спочатку скористайтеся:

$pg_dump --schema ... 

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

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

$pg_dump --table=.. <or> --exclude-table=..

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

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

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

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

На це питання досить відповіли, але я хотів би доповнити відповідь X-Istence і Дани Сане невеликою пропозицією.

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

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

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

Ось що я намагаюся зробити у своїх проектах:

• окремі дані та схеми та дані за замовчуванням.

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

За замовчуванням у базі даних (для налаштування нових проектів) - це простий файл SQL під контролем версій.

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

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

Погляньте на інші великі проекти з відкритим кодом з відкритим кодом (piwik або улюблену систему cms), всі вони використовують оновлення сценаріїв (1.sql, 2.sql, 3.sh, 4.php.5.sql)

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

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

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

Я рекомендую neXtep для версії, що контролює базу даних, вона має гарний набір документації та форумів, що пояснює, як встановити та виникли помилки. Я перевірив його на postgreSQL 9.1 і 9.3, мені вдалося змусити його працювати для 9.1, але для 9.3 він, здається, не працює.

Що я роблю в своїх особистих проектах, це те, що я зберігаю всю свою базу даних у папці "вікна", а потім вказую на MAMP, WAMP робочий процес, щоб використовувати її прямо звідти. Таким чином, база даних завжди оновлюється там, де коли-небудь мені потрібно зробити якісь розробки. Але це тільки для дев! Живі сайти використовують власний сервер для цього поза курсом! :)

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

Ось як я це роблю:

Оскільки у вас є вибір на вибір типу БД, використовуйте базу даних на базі файлів, наприклад, firebird.

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

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

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

Ми використовували соціальний веб-сайт за стандартною конфігурацією LAMP. У нас був сервер Live, тестовий сервер та сервер розвитку, а також місцеві машини розробників. Усі були керовані за допомогою GIT.

На кожній машині у нас були файли PHP, але також служба MySQL та папка із зображеннями, які користувачі завантажуватимуть. На Live сервері виросло близько 100 К (!) Періодичних користувачів, дамп - близько 2 ГБ (!), Папка "Зображення" - приблизно 50 ГБ (!). На той момент, коли я пішов, наш сервер досягав межі свого CPU, Ram, і, головне, одночасних лімітів мережевого підключення (Ми навіть склали власну версію драйвера мережевої карти, щоб максимально перевищити «lol» сервера). Ми не могли ( і не варто вважати, що на вашому веб-сайті ) розміщувати 2 ГБ даних і 50 ГБ зображень у GIT.

Щоб легко керувати усім цим під GIT, ми б ігнорували двійкові папки (папки, що містять зображення), вставляючи ці шляхи до папки у .gitignore. У нас також була папка під назвою SQL за межами шляху Apache documentroot. У цій папці SQL ми помістимо наші файли SQL від розробників у додаткові нумерації (001.florianm.sql, 001.johns.sql, 002.florianm.sql тощо). Цими файлами SQL керував і GIT. Перший файл sql дійсно містив би великий набір схем БД. Ми не додаємо дані користувачів у GIT (наприклад, записи в таблиці користувачів або таблицю коментарів), але такі дані, як конфігурація чи топологія чи інші дані щодо конкретних сайтів, зберігалися у файлах sql (а отже, і GIT). Переважно його розробники (які найкраще знають код), які визначають, що і чого не підтримується GIT щодо схеми та даних SQL.

Коли він дійшов до випуску, адміністратор заходить у сервер розробок, з’єднує живу гілку з усіма розробниками та потрібними гілками на машині розробки з гілкою оновлення та переміщує її на тестовий сервер. На тестовому сервері він перевіряє, чи є процес оновлення для Live-сервера все-таки дійсним, і швидко поспіль вказує весь трафік Apache на сайт-заповнювач, створює дамп БД, вказує робочий каталог з "живого" на "оновлення" ', виконує всі нові sql файли в mysql і повертає трафік назад на правильний сайт. Коли всі зацікавлені сторони погодились після перегляду тестового сервера, адміністратор зробив те саме, що і від тестового сервера до сервера Live. Після цього він об'єднує живу гілку на виробничому сервері, до ведучої гілки через усі сервери та перезавантажує всі живі гілки.

Якщо на тестовому сервері виникли проблеми, наприклад. у злиттях було занадто багато конфліктів, тоді код було повернено (вказуючи робочу гілку назад на "живе"), а файли sql ніколи не виконувалися. У той момент, коли були виконані файли sql, це було розцінено як незворотну дію. Якщо файли SQL не працювали належним чином, то БД було відновлено за допомогою дампа (і розробники сказали, що надавали неправильно перевірені файли SQL).

Сьогодні ми підтримуємо як папку sql-up, так і sql-down, з еквівалентними іменами, де розробники повинні перевірити, що обидва оновлені sql-файли можуть бути однаково знижені. Це в кінцевому підсумку може бути виконане за допомогою скрипту bash, але його гарна ідея, якби людські очі продовжували стежити за процесом оновлення.

Це не велико, але керовано. Сподіваюсь, це дає уявлення про реальний, практичний, відносно великий доступний сайт. Нехай це трохи застаріло, але все-таки слідувало.

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

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

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

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

Оновлення 26 серпня 2019 року:

Netlify CMS робить це з GitHub, тут можна знайти приклад реалізації з усією інформацією про те, як вони реалізували його netlify-cms-backend-github