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

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

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

Так. Ви повинні мати можливість відновити будь-яку частину вашої системи з управління джерелами, включаючи базу даних (і я б також стверджував певні статичні дані).

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

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

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

Процес оновлення / тегу / розгалуження має бути таким же, як і решта вихідного коду - мало сенсу робити це, якщо ви не можете пов’язати версію бази даних з версією програми.

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

Так.

який найкращий спосіб зберегти його та оновити там?

Гм. Напишіть сценарій-конструктор схем. Перевірте це після внесення змін. Перевірте це перед тим, як його запустити.

Важко визначити, про що ви просите.

Напишіть формальні сценарії міграції схем. Перевірте їх після тестування. Перевірте їх перед запуском.

Що ще там?

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

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

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

Так

Сценарії бази даних (ddl, dml) - це код. Весь код повинен бути у системі управління версіями.

Міграції

• Використовуйте міграцію баз даних

Дозволяє використовувати ті самі файли db у розробці, qa та випусках.

• Відпустіть до бази даних з номером релізу

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

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

Ми також намагалися автоматизувати це за допомогою інструментів порівняння баз даних (порівняйте головний та клієнтський db), і це допомогло, але ви не можете довіряти таким інструментам на 100%, вам також обов’язково потрібен процес перегляду.

Так

А далі, вам захочеться гілок .

Я використовую Git для гілок:

• для розробки за особливістю (як ми робимо для регулярної розробки решти програми)

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

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

Я ще не знайшов системи "все в одному" [для PostgreSQL], тому мені довелося писати функції / сценарії, щоб належним чином переосмислитись під час об'єднання гілок (наприклад, будь-який індекс із гілки виробництва не слід змінювати, оскільки клієнти покладаються на них, тоді як індекси + сторонні ключі від галузі розробки, які перетинаються із вмістом виробництва, повинні бути повторно застосовані: він працюватиме не для всіх додатків, але охоплює всі випадки нашої програми, так що це досить добре).

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

Для Java наша команда використовує Flyway , який ми вважаємо дійсно простим у використанні та потужним.

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

Про Liquibase вже згадувалося - це хороше рішення, але я вважав його більш громіздким, ніж альтернативи, як Flyway.

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

Ось проблема, яку я бачив багато разів, коли в базах даних про розробку немає керування версіями або управління змінами. Програміст A вносить зміни в таблицю, перегляд чи процедуру. Програміст B вносить зміни в те саме, що переробляє те, що робив програміст A. Або DBA відновлює виробничий БД до розробки та замінює зміни. Я бачив, як подібні речі викликають багато горя, тому багато разів це не смішно. І це лише на системах розвитку. Речі можуть стати справді безладними, коли постановка / тестування і навіть виробничі сервери потрапляють у це.

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

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

Для наших проектів PHP / MySQL ми використовували (колись) маленький інструмент під назвою Сходи . Він створений для сприяння органічному зростанню бази даних з часом. Усі міграції проекту зберігаються в контролі редакції / джерела / версії та відстежуються разом з кодом.

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

О, і останнє доповнення - база даних відрізняється. Запустіть diff-saveкоманду, додайте та видаліть кілька стовпців із бази даних та виконайте її diffкоманду. Ви побачите автоматично згенерований код міграції на основі стану бази даних.

DataGrove вирішує деякі згадані тут проблеми (наприклад, jfrankcarr ).

Він відстежує всі зміни в БД і дозволяє зберегти версію всього стану БД у сховище. Потім він дозволяє нереститися декількох віртуальних копій однієї БД, тому кожен розробник або DBA може мати свою окрему копію (кожна віртуальна копія може бути породжена з іншої версії). Це переконається, що ніхто не перекриє чийсь код / ​​зміни. Кожна з віртуальних копій також відслідковується в одних сховищах, тому всі стани БД можна легко поділити і відтворити.

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

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

MONyog має функцію під назвою CSO (Custom SQL Objects), яка може стежити за зміною конкретного набору даних. Додавання ОГС описано тут . Тепер у розділі історії моніторів MONyog ви можете отримати зміни протягом певного періоду часу. Найкраще, він дає візуальний звіт у html-сторінці. Звіт буде виглядати приблизно так