Я много думал и читал на эту тему. Это широкая тема контроля конфигурации и стратегии управления изменениями. У 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). Мы поставили им контроль источников и поддерживали там. Я думаю, что специализированное решение, такое как liquibase, может работать лучше.
Этот подход хорошо работает при наличии 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. В answer2 мне нужно искать все изменения. Также в ответе 2 скрипт в системе управления версиями имеет тенденцию быть сложным и сложным. Трудно найти информацию.
Ответ 3
Если 3 верно. Обратите внимание, что в этой ситуации у вас нет ограничения 6, то есть: у вас нет серверов разработки, тестирования, продуктов. Только рабочий сервер. Вы можете использовать триггеры DDL, чтобы регистрировать, какие изменения были сделаны. Это в основном используется, чтобы отговорить людей от злоупотребления своими грантами DDL. Если возникнет какая-либо проблема, вы можете найти ответственного. Чтобы это работало, каждый человек должен соединиться со своей учетной записью пользователя, а учетная запись приложения не должна иметь никаких грантов DDL. Так как каждый разработчик знает аккаунт Приложения и может им пользоваться.
Ответ 4
Если у вас есть 3 и 5. Обратите внимание, что в этой ситуации у вас нет ограничения 6, то есть: у вас нет серверов разработки, тестирования, продукта. Только рабочий сервер. Вместо триггера для сохранения изменений. Вы используете внешний инструмент для поиска изменений и сохранения сценариев DDL в системе контроля версий.
Если этот инструмент имеет возможность записывать, кто сделал изменения, это было бы полезно. Обратите внимание, что в этом решении вы теряете дополнительный DDL, который делается с интервалами.