Чи використовуєте ви керування джерелами для елементів своєї бази даних? [зачинено]

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

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

Однак я знаю, як йде ця історія. Лише питання часу, перш ніж все вийде просто не так, і щось пропаде.

Чи є найкращі практики для цього? Які стратегії спрацювали для вас?

Потрібно прочитати Отримайте свою базу даних під контролем версій . Перевірте серію дописів К. Скотта Аллена.

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

Самі бази даних? Ні

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

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

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

Однак, трохи попрацювавши, ви могли зробити те саме. Будь-які зміни DDL (ALTER TABLE тощо) можуть зберігатися у текстових файлах. Зберігайте систему нумерації (або штамп дати) для імен файлів і застосовуйте їх послідовно.

Rails також має таблицю "версії" в БД, яка відстежує останню застосовану міграцію. Ви можете зробити те ж саме легко.

Ознайомтеся з LiquiBase щодо управління змінами бази даних за допомогою керування джерелом.

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

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

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

Так. Код - код. Моє правило полягає в тому, що мені потрібно вміти створювати та розгортати додаток з нуля , не дивлячись на розробку чи виробничу машину.

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

Я вважаю, що це було зроблено з NaNt / CruiseControl.

ТАК, я думаю, що важливо версію вашої бази даних. Не дані, а схема для певних.

У Ruby On Rails це обробляється рамками з "міграціями". Щоразу, коли ви змінюєте db, ви створюєте скрипт, який застосовує зміни, і перевіряєте його на контроль джерела.

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

Нові проекти баз даних у Visual Studio забезпечують управління джерелами та зміни сценаріїв.

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

Схема db "подрібнена", щоб створити багато, багато маленьких .sql файлів, один на команду DDL, що описує БД.

+ том

Додаткова інформація 2008-11-30

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

Оскільки схема "подрібнена" у файли sql, керування джерелом працює чудово.

Один з причин - це те, що вам потрібно мати інший спосіб мислення, коли ви використовуєте db-проект. Інструмент має "проект db" у VS, який є просто sql, а також автоматично генеровану локальну базу даних, яка має схему та деякі інші дані адміністратора - але жоден із ваших даних програми, а також ваш місцевий dv db, який ви використовуєте для робота розробників даних додатків. Ви рідко знаєте про автоматично створений db, але ви мусите його знати там, щоб ви могли залишити його в спокої :). Цей спеціальний db чітко впізнаваний, оскільки він має Посібник у своїй назві,

Проект VS DB виконує хорошу роботу з інтеграції змін DB, які внесли інші члени команди, у ваш локальний проект / асоційований db. але вам потрібно зробити додатковий крок, щоб порівняти схему проекту з локальною схемою dev db і застосувати моди. Це має сенс, але спочатку здається незручним.

Проекти БД - це дуже потужний інструмент. Вони не тільки генерують сценарії, але можуть застосувати їх негайно. Будьте впевнені, що не знищуйте з ним свій виробничий db. ;)

Мені дуже подобаються проекти VS DB, і я сподіваюся використовувати цей інструмент для всіх своїх DB проектів, що рухаються вперед.

+ том

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

Я можу запропонувати використовувати надбудову SSMS під назвою ApexSQL Source Control . Це дозволяє розробникам легко відображати об’єкти бази даних за допомогою системи управління джерелом через майстра безпосередньо з SSMS. Доповнення включає підтримку TFS, Git, Subversion та інших систем SC. Вона також включає підтримку джерела, що контролює статичні дані.

Завантаживши та встановивши ApexSQL Source Control, просто клацніть правою кнопкою миші базу даних, у якій потрібно керувати версіями, та перейдіть до підменю ApexSQL Source Control у SSMS. Клацніть на опції управління базою даних до джерела, виберіть систему управління джерелом та модель розробки. Після цього вам потрібно буде надати інформацію про вхід та рядок сховища для вибраної системи управління джерелом.

Ви можете прочитати цю статтю для отримання додаткової інформації: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

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

Так, ми робимо це, зберігаючи наш SQL як частину нашої збірки - ми зберігаємо DROP.sql, CREATE.sql, USERS.sql, VALUES.sql та версію контролю над ними, тому ми можемо повернутися до будь-якої тегованої версії.

У нас також є завдання мурашки, які можуть відтворювати db, коли це потрібно.

Крім того, SQL потім позначається разом з вашим вихідним кодом, який додається до нього.

Найуспішніша схема, яку я коли-небудь використовував для проекту, поєднала резервні копії та диференційні файли SQL. В основному ми би взяли резервну копію нашого db після кожного випуску і зробимо дамп SQL, щоб ми могли створити порожню схему з нуля, якщо нам це потрібно. Тоді в будь-який час, коли вам потрібно було внести зміни в БД, ви додасте змінний скрипт до каталогу sql під контролем версії. Ми завжди будемо префіксувати порядковий номер або дату до імені файлу, тому перша зміна буде чимось на зразок 01_add_create_on_column.sql, а наступним сценарієм буде 02_added_customers_index. Наша машина CI перевірила б їх та запустила їх послідовно на новій копії db, яка була відновлена ​​з резервної копії.

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

Ми контролюємо джерело всіх наших об’єктів, створених дабазами. І тільки для того, щоб розробники були чесними (адже ви можете створювати об'єкти без того, щоб вони знаходилися в Source Control), наші dbas періодично шукають нічого, що не знаходиться в контролі джерела, і якщо вони щось знайдуть, вони скидають його, не запитуючи, чи це нормально.

Я використовую SchemaBank для контролю версій усіх змін моєї схеми бази даних:

• з 1-го дня я імпортую в неї свій дамб-схему db
• я почав змінювати свою схему за допомогою веб-браузера (тому що вони є SaaS / хмара)
• коли я хочу оновити свій сервер db, я генерую з нього скрипт зміни (SQL) і застосовую до db. У Schemabank вони доручають мені виконувати свою роботу як версію, перш ніж я можу створити сценарій оновлення. Мені подобається така практика, щоб я завжди міг простежити назад, коли мені потрібно.

Правило нашої команди НІКОЛИ не торкайтеся сервера db безпосередньо, не зберігаючи спочатку проектні роботи. Але буває, хтось може спокуситися порушити правило, заради зручності. Ми б імпортували дамп схеми знову в schemabank і дозволили йому виконувати розріз і ламати когось, якщо буде виявлено розбіжність. Хоча ми могли б генерувати з нього сценарії alter, щоб синхронізувати наш db та схеми, ми просто ненавидимо це.

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

Досить акуратний інструмент розробки веб-схем із керуванням версією n управління змінами.

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

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

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

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

Я використовую сценарії SQL CREATE, експортовані з MySQL Workbech, потім, використовуючи їх функцію "Експорт SQL ALTER", я закінчую серією створення скриптів (пронумерованих звичайно) та сценаріями alter, які можуть застосовувати зміни між ними.

3. - Експорт сценарію SQL ALTER Зазвичай вам доведеться писати заяви ALTER TABLE вручну, відображаючи ваші зміни, внесені в модель. Але ви можете бути розумними і дозволити Workbench робити важку роботу за вас. Просто виберіть у головному меню Файл -> Експорт -> Спрямований сценарій SQL ALTER ....

Це запропонує вам вказати файл SQL CREATE, з яким слід порівнювати поточну модель.

Виберіть сценарій SQL CREATE на кроці 1. Потім інструмент генерує сценарій ALTER TABLE для вас, і ви можете виконати цей скрипт проти вашої бази даних, щоб оновити його.

Це можна зробити за допомогою браузера MySQL Query Browser або mysql client.Voila! Ваша модель та база даних тепер синхронізовані!

Джерело: MySQL Workbench Community Edition: Керівництво по синхронізації схем

Усі ці сценарії, звичайно, знаходяться під контролем версій.

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

Було багато дискусій щодо самої моделі бази даних, але ми також зберігаємо необхідні дані у .SQL-файлах.

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

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

У нас був би файл, який називається в currency.sqlумовах підриву. В якості ручного кроку в процесі збирання ми порівнюємо попередній Currency.sql з останнім і пишемо сценарій оновлення.

Ми версії та джерела контролюємо все навколо наших баз даних:

• DDL (створити та змінити)
• DML (довідкові дані, коди тощо)
• Зміни моделі даних (за допомогою ERwin або ER / Studio)
• Зміни конфігурації бази даних (дозволи, об'єкти безпеки, загальні зміни конфігурації)

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

Я вважаю, що кожна БД повинна знаходитися під контролем джерела, а розробники повинні мати простий спосіб створити свою локальну базу даних з нуля. Натхненний Visual Studio для професіоналів баз даних, я створив інструмент з відкритим кодом, який скриптує бази даних MS SQL та забезпечує простий спосіб їх розгортання у вашому локальному двигуні БД. Спробуйте http://dbsourcetools.codeplex.com/ . Повеселіться, - Натане.

Якщо ваша база даних - це SQL Server, у нас може бути саме те рішення, яке ви шукаєте. Тепер випущено SQL Source Control 1.0.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

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

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

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

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

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

Ми переносимо всі бази даних до джерела контролю. Ми використовуємо sqlcompare для скриптування бази даних (на жаль, функція видання професії) та передачі цього результату у SVN.

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

Найбільше вам удачі, чим раніше ви спробуєте це, тим швидше розберете свої проблеми.

Я використовував інструмент dbdeploy від ThoughtWorks за адресою http://dbdeploy.com/ . Це заохочує використання сценаріїв міграції. Кожен випуск ми консолідували сценарії змін у єдиний файл, щоб полегшити розуміння та дозволити DBA «благословити» зміни.

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

Інструмент, який я використовував у минулому, і який допомагав у цьому, - це SQL Delta. Він покаже вам відмінності між двома базами даних (SQL-сервер / Oracle, я вважаю) та генерує всі сценарії зміни, необхідні для міграції A-> B. Ще одна приємна річ - це показати всі відмінності між вмістом бази даних між виробничою (або тестовою) БД і вашою БД розробки. Оскільки все більше і більше додатків зберігають конфігурацію та стан, що має вирішальне значення для їх виконання у таблицях баз даних, може бути справжнім болем мати скрипти зміни, які видаляють, додають та змінюють відповідні рядки. SQL Delta показує рядки в базі даних так, як вони виглядали б у інструменті Diff - змінені, додані, видалені.

Відмінний засіб. Ось посилання: http://www.sqldelta.com/

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

RedGate також робить знімки даних, хоча я особисто не працював з ними, вони настільки ж надійні.

FYI Це також було піднято кілька днів тому Даною ... Збережені процедури / схема БД в керуванні джерелами