alexeyvgMordashovА вот тут вы неправы. На самом деле поддержка версионности когда разработка базы ведется в скриптах в 100 раз удобнее, чем когда разработка ведется в CASE средстве.

Представим что нам нужно сделать 100 измениний в схеме данных (модели).
Каждое такое изменение может повлиять на данные в базе. Когда мы пишем скрипты, мы об этом заботимся сразу. Например:

UPDATE supplier set supplier_name = 'N/A' where supplier_name is null
ALTER TABLE supplier
MODIFY supplier_name varchar2(100) not null;

Когда мы девелопим модель в CASE средстве - нам от миграции тоже никуда не деться (!!!), только это будут костыли , скрипты по миграции где-то сбоку. 100 костылей , где-то сбоку, причем нам надо помнить о порядке, в котором их применять, а то ведь не сработают.
Где удобство то??Безусловно, изменения нужно делать в скриптах, хранить в версионном хранилище исходников, привязывать к бизнес-требованиям, проектам и запросам на изменения и т.д и т.п.

Но вопрос был про (как минимум) рисовалку диаграмм, ну или далее про CASE - средства.

Ведь хотя бы диаграммы в проекте нужны; и версии их хорошо-бы хранить, в т.ч. в доках ,в какой-нибуть wiki-документации к проекту, и несколько вариантов делать и обсуждать... Или как - при обсуждении модели данных делаем скрипты изменений (несколько вариантов) и перед встрече их раздаём? :-)

Ну и речь о том, что у производителя СУБД встроенные средства для всего этого неудобны. И зачем себя ограничивать одним продуктом?

Диаграммы да вещь неплохая :) Вот хранить их версионность -вот тут несколько вопросов. Например, у нас по ходу разработки несколько раз менялся взгляд на версионность (надо было хранить исторические данные и по разному их применять : интервалы актуальности версий и тд и тп), и зачем нам хранить то, что уже не на продакшене давно и тем более не в девелопменте? Описывать каждое изменение - (в смысле комментариев) накладно, и кажется сизифовым трудом, когда разработка действительно agile. Другое дело - что под конец разработки (релиз) - в идеале надо бы выкатить диаграмму, которую потом благодарные пользователи базы или разработчики другой стороней тулзы которая полезет в нашу базу данных будут использовать, чтобы подглядеть связи. Как я уже сказал - спасет Reverse. Или , если уж мы даем права на чтение из БД, то Reverse могут сделать все желающие сами :)

Я не очень понимаю зачем раздавать скрипты изменений при встрече :) Если команда co-located, то изменения можно обсуждать по мере их возникновения за белой доской. Т.е. захотели вы что-нибудь нормализовать например - рисуете разработчикам на доске новые таблички - они головой кивают. И вперед - можно делать скрипты.

alexeyvgMordashovДиаграммы да вещь неплохая :) Вот хранить их версионность -вот тут несколько вопросов. Например, у нас по ходу разработки несколько раз менялся взгляд на версионность (надо было хранить исторические данные и по разному их применять : интервалы актуальности версий и тд и тп), и зачем нам хранить то, что уже не на продакшене давно и тем более не в девелопменте?Зачем хранить? Так это ничего не стоит. А через несколько лет легче будет понять, чем вызвано именно такое решение, да и какое оно вообще было, осебенно учитывая, что коллектив поменяется процентов на 100-200 :-)

Вообще, обычно трудно объяснить, зачем хранить исходники в соурс-контроле - вот говорят, "зачем нам хранить то, что уже не на продакшене давно", и всё :-(



alexeyvg,

Сорс контроль позволяет откатиться на любой момент. Тут все ясно. Посмотреть кто ошибку принес :) А вот версии схемы не очень понятно что позволяют. Сама по себе модель данных не описывает причины принятия решения о конкретной реализации. И кстати, модель на любой момент времени вы можете восстановить - просто накатив на пустую базу лишь частичный набор скриптов - и посмотреть при желании модель старым добрым Reverse.
По мимо прочего - у нас например 100 измений базы данных за 6 месяцев. Что 100 версий модели хранить?

Ошибок моделирования как таковых - практически нет. Есть постепенное накапаливание наших знаний о предметной области- и как следствие изменение модели данных, которую мы создаем.
Да мы можем посмотреть на модель 2 летней давности. Но что нам это даст? Констатацию факта что наше понимание значительно возросло и только.
Через 5 лет - там будет 5000 изменений и 5 большх версий системы, 20 маленьких релизов и 200 релизов баг фиксов . Вы и правда хотите вновь пришедшего человека заставить проходить весь этот путь? Когда же он начнет работать, месяцев через 6 ?

Серж,

автор
Вот меня и интересует как можно обойтись без case и гарантированно обновить базу? Если действительно есть варианты, хочется услышать подробное описание.

Это конечно же Version Control (любой). Сам подход уже описан: каждый скрипт изменения пишем в файл , называем файлы 1.sql, 2.sql .. и так далее. В том месте, где у нас появилась новая ветка (вторая версия) мы начинаем фактически поддерживать две версии продукта. Например, со скрипта под номером 100 у нас присутствуют скрипты с одинаковыми номерами (101, 102, 103..110) в двух раздельных ветках в Vesrion Control. Когда наступает пора merge, мы просто добавляем баг-фиксы из 1ой версии во вторую ветку присвоив им номера 111,112,113..120. Теперь вторая версия включает новые фичи + багфискы из первой версии. Естественно, стоит посмотреть нужны ли эти фиксы вообще, может быть они на таблицу, которую во второй версии удалили, но ведь и применении CASE не автоматизирует процесс принятия решения при Merge. Вам только показывается разница схем, а вот какую версию брать - приходится решать самостоятельно, не так ли?

Более того, нам не приходится заботиться о переносе данных в момент когда надо выпускать релиз. Потому что каждый скрипт изменения - это законченная операция изменения, включая перенос данных.

Vika Vinner,

авторПрограммно-центрированным разработкам перейти к Модельно-проектным

Вообще-то мир движется в сторону адаптивных технологий разработки ПО, и следовательно эволюционного проектирования. И модель в этом мире далеко не центр, а всего лишь артефакт на отшибе, частенько забываемый.