Я багато думав і читав на цю тему. Це широка тема управління конфігурацією та стратегія управління змінами. CMMI має домен у цій темі. Навіть у компаніях, які мають акредитацію CMMI 3-5, вони іноді не контролюють версії своїх баз даних.
На це питання слід відповісти, маючи на увазі наступні обмеження .
- У вас є хранитель, і кожен DDL виконується цим власником.
- Інші люди мають можливість виконувати оператори DDL.
- Вам потрібно лише зареєструвати зміни, які були зроблені, але вам не потрібно порівнювати великі відмінності.
- Дизайн вашої бази даних здійснюється за допомогою зовнішнього інструменту, після чого публікується в базі даних. Цей зовнішній інструмент може бути навіть сценаріями DDL в керуванні джерелами. Але ключовим моментом є те, що ви керуєте цим джерелом, а потім публікуєте в базі даних.
- Вам не потрібно знати миттєві зміни, але час від часу: тобто щогодини, щодня.
- У вас визначена структура сервера: Розробка, Тест, Виробництво. І хороша стратегія тестування.
Відповідь 1
- якщо вірно 1, 4,6, то можна використовувати зовнішній елемент керування джерелом. Наприклад
- Embercadero має інструмент управління зміною баз даних ( http://www.embarcadero.com/products/db-change-manager-xe ). Який має можливість повернути інженеру базу даних (Oracle) і поставити її в їх джерело управління. Тоді будь-яка кількість розробників, dba може дійти до цієї схеми та внести в неї зміни.
- Oracle SQL Designer подібний до цього підходу.
- Якщо ви створюєте сценарії таблиць для керування джерелом (svn, mercurial тощо) та підтримуєте їх також одне і те ж.
- http://www.liquibase.org - це автоматизований підхід вище.
- Я написав генератор коду, який генерував оператори DAL (Data Access Layer), DDL (Create Table). Ми поставили їм контроль над джерелами і там підтримували. Я думаю, що спеціально розроблене рішення, як, наприклад, ліквідова база, може працювати краще.
Цей підхід добре працює, якщо є 6. Ви ставите оператори DDL, що також є кодом, у керування джерелами та підтримуєте його. Ніхто не змінить тестові та виробничі сервери без належного розгляду.
Недоліки полягають у тому, що якщо ви з будь-якої причини внесете будь-які зміни у виробничі або тестові сервери, швидке виправлення помилок, зміна первинного ключа тощо. Вам також потрібно скачати ці зміни на сервер розвитку. Оскільки насправді сервер розвитку - це ваша НАРОДНА ПРАВДА. Не навпаки.
Це дуже орієнтований на розробник підхід. Але коли ви вперше розробляєте новий модуль, він працює досить добре.
Відповідь 2
- якщо вірно 1 і 6:
Аналогічний підхід до відповіді 1 - це підтримка сервера розробки. Усі користувачі її змінюють. Тоді коли настає час оновлення. Ви використовуєте інструмент порівняння бази даних. Отримайте їх як сценарії, поставте під контроль джерела.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
Різниця між відповідями 1 та відповіддю 2 полягає в тому, що у відповіді 1 ви збираєте виписки DDL для всієї бази даних та зберігаєте їх. У відповіді 2 потрібно зберігати кожну версію змін.
- Старт
- V1
- V2
- V3
- ...
Якщо ви помістите стовпчик до таблиці, а пізніше вирішите його видалити. Ваші сценарії покажуть це у answer2, а у answer1 ви побачите лише останню версію. І вам потрібно порівняти V2 і V1, щоб побачити відмінності. Особисто мені подобається відповідь 1 кращою, оскільки я можу легко порівняти Start і V3, V1 і V3. У відповідь2 мені потрібно шукати всі зміни. Також сценарій відповіді 2 у контролі джерела має тенденцію до великого удару, складний сценарій. Важко знайти інформацію.
Відповідь 3
Якщо 3 відповідає дійсності. Зауважте, що в цій ситуації у вас немає обмеження 6, тобто: у вас немає серверів розробки, тестування, продуктів. Тільки сервер виробництва. Ви можете використовувати тригери DDL для реєстрації змін. Це в основному використовується для відсторонення людей від зловживань їх DDL-грантами. Якщо виникає якась проблема, ви можете знайти відповідальність. Для цього кожна людина повинна з'єднатися зі своїм обліковим записом користувача, а обліковий запис програми не повинен мати жодних грантів DDL. Оскільки кожен розробник знає акаунт програми і може ним користуватися.
Відповідь 4
Якщо у вас є 3 і 5. Зауважте, що в цій ситуації у вас немає обмеження 6, тобто: у вас немає серверів розробки, тестування, продуктів. Тільки сервер виробництва. Замість тригера зберігати зміни. Ви використовуєте зовнішній інструмент пошуку змін і зберігаєте сценарії DDL у контролі джерела.
Якщо цей інструмент має можливість записувати, хто змінив, було б корисно. Зауважте, що в цьому рішенні ви втрачаєте додатковий DDL, який робиться з інтервалом.