Vika Vinner,

Отличный документ. Спасибо!
С сожалением правда обнаружил, что рефакторинг баз данных не поддерживает ни один из лидерующих продуктов (*вот он последний бастион вотерфола*)
Что в моем понимании рефакторинг - (тут я воспользуюсь шаблоном из Скотта Эмблера "Рефакторинг баз данных") -
три шага.
1. Изменение схемы данных.
2. Процедура переноса данных
3. Изменение программ доступа.

Ну понятно, что схему то может любое завалящее средство изменить. Программы доступа - тут конечно в код средство не полезет. Но если например табличку поменять - то в идеале средство само должно предложить поменять вьюхи зависимые и процедуры. Ну хотя бы зависимости показывает, и то хорошо.
Самый большой пробел с переносом данных. Тут провал уровня индустрии на мой взгляд. Вот вы тут пример приводили - Платформа TNP. Достойный CASE-средства кандидат, бесспорно. Только вот представьте чего стоит в плане миграции данных переезд например с 12ой версии на 13ую.
Изменилось до неузнаваемости 100 таблиц, 100 пропало , 100 новых. Как это разрулить?
И ведь это ни на кого-то упадет , ни на C# кодера (он не умеет) , ни на ДБА - ему в сущности до фени , он за производительность и бэкапы отвечает и в бизнесе не сечет, а на родного дата-аналитика. И то средство , в которое корпорации вкладывают огромные средства, то средство,которое развивалось ни один десяток лет, этот венец творения - ничегошеньки не может.
Внимание вопрос, а нужно ли оно [такое] вообще? Получается что 20+ лет до создателей средств проектирования баз данных так и не дошло что они имеют дело с ДАННЫМИ , а не набором атрибутов и связей ? Разве это не грустно?

Чтобы визуально представить себе предметную область достаточно дешевых инструментов:
бумага+карандаш,доска+маркер, встроенное в СУБД средство, Visio или Dezign за 40 баксов (или сколько он там счас стоит)

baike2000 muk07
авторЧто я могу сделать в Power Designer (или в др CASE) из того что я не могу сделать в Management Studio, работая исключительно с MS SQL SeRVER?

Интересно, эточто не ответы на ваш вопрос?

авторВы на рабочей базе будете проектировать? Или на тестовой, или на девелоперской?

Как вы версии будите хранить и сравнивать?

Как несколько вариантов сделать для обсуждения - несколько баз делать?

Ах, ну да, вы все это сможете сделать, правда времени затратите и через одно место, но сможете...

Но если так, то ваш вопрос изначально не имел смысла. Да вы все сможете сделать, но только это будет не удобно.

А вот тут вы неправы. На самом деле поддержка версионности когда разработка базы ведется в скриптах в 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 костылей , где-то сбоку, причем нам надо помнить о порядке, в котором их применять, а то ведь не сработают.
Где удобство то??

alexeyvg,

авторДа главную вещь не сделаете - как вы деплоить будете свой проект?

Вы на рабочей базе будете проектировать? Или на тестовой, или на девелоперской?

Как вы версии будите хранить и сравнивать?

Как несколько вариантов сделать для обсуждения - несколько баз делать?

И главное, из-за чего этот геморрой - потому что лень было прочитать хелп и найти нужную галку, чтобы правильно скрипт сгененрить???

Ну ладно, ервин, ПД - они дорогие - ну так можно и подешевле средство найти.

У нас все в скриптах - поэтому со деплоем проблем нет. И с миграцией по окружениям (продакшен- тест- девелопмент ) тоже. Просто каждому изменению присваивается номером - он только возрастает. Вот вам готовая версионность. Написать деплой для таких скриптов (всех делов на час) - и после этого готовое решение.

Версии хранятся в source control'e . Обсуждение обычно затрагивает 3-7 таблиц - прикинуть их на доске не составляет труда. Вряд ли вы будете обсуждать 50 таблиц всем скопом. А если таки хотите -при желании в любой момент можно сделать Reverse базы хоть в Visio и повесить на стенку.

За muk07 не могу сказать, а наш вариант родился из-за того , что миграцией данных CASE средства принебрегают.