А почему сразу не рисовать диаграмму в родной СУБД?
Зачем этот промежуточный шаг?

неубедительно.
нарисую в erwin
потом при при переходе к конкретной субд получу кучу неточностей
и буду их править уже в рамках субд

Не нужна мне ни концептуальная ни логическая.
Достаточно, например, такой картинки.

авторв ней ни сути не характера ни воплощения не видно
вы из филологии или искусствоведения?

именно так
без характера и воплощения

спасибо за напутствие в дорогу.
вы меня позабавили

Разберём комментарии alexeyvg:
авторА вы за ошибки проектирования сами платите или фирма? :-)

Ответа не заслуживает.
авторЭто картинка (Database Diagrams) из средства проектирования, встроенного в комплект микрософтовского софта для работы с сервером. Так что картиночка-то тоже из средства проектирования БД.

Совершенно верно, я всего лишь утверждал,что почти все СУБД имеют такой собственный инструмент. Им и надо пользоваться. В противном случае Вас ждёт конверсия из CASE средства типа erwin в native базу данных, которая будет выполнена нечисто. И доработка в среде СУБД всё равно вас ждёт.
авторКроме этого софта, есть и другие средства проектирования, в т.ч. и у микрософта.
Ломимся в открытую дверь.
авторЕсли вы выбрали именно это средство, незачем кричать всем, что оно самое удобное, производительное, полное, лучьше всего позволяет организовать работу компании.
Неподходящий глагол "кричать". Я не утверждал, что "оно самое удобное, производительное, полное, лучьше всего позволяет организовать работу компании". Я утверждал, что применение не родных (не заточенных) на конкретную БД средств приведёт к лишней работе по доработке БД средствами родной СУБД. В 2000-2002 гг.группа из 3 человек (я в том числе) создали АСУ нашего ВУЗа. 185 таблиц. Сильная связность. 13 клиентов. ~500 процедур и функций. В общем задача не самая сложная, бывает хуже, но и не простая. Первоначальный проект БД делали в ERWIN 3.5, после чего дали зарок не подходить к ней близко, т.к. всё пришлось дорабатывать, и довольно долго.
Моё утверждение звучит так: целесообразнее пользоваться построителем диаграмм, входящим в целевую БД. Могут быть исключения - гетерогенные и/или нереляционные БД.
авторВсё таки выбранная вами программа совсем убога.
это утверждение совсем вас дискредитирует, видимо вы не знакомы с ms sql server, это ещё не грех, но и не повод для гордости.

Вообще то мой пост был сознательно немного провокационным. Я знал что будут клевать, правда не учёл что пишу в выходные. К сожалению, человека, который мог бы выдвинуть аргументированные возражения пока не нашлось. Доживём до понедельника.

наконец то - первый разумный комментарий.
авторДругие верят, что в течении разработки ПО выясняется куча новой информации, о которой сам заказчик не подозревал, или забыл, или передумал.
- да, я никогда не видел БД, которая не изменялась бы в течение жизни.
Конечно, для оч. больших коллективов нужны team средства.
Я лично с такой ситуацией дела не имел. БД всегда разрабатывалась силами 1-3 человек. И рады бы были увеличить число разработчиков, но это не поддавалось распараллеливанию. Как говорил доктор Хасс в МЕРТВОМ СЕЗОНЕ - если 9 беременных женщин собрать вместе, то ребёнок не родится через месяц.
Кроме того, то о чём вы говорите скорее средство коллективного доступа к результатам разработки, а не само средство разработки. Это бесспорно очень нужно в первую очередь кодерам.
Можете ли предложить ещё какие то ситуации в которых было бы целесообразно применение CASE средств именно разработки.

я понял так что Вы более или менее подтверждаете мою точку зрения.
Надо придумать такую провокацию, чтобы на меня набросились оппоненты.
Меня тут как то поклевали за мою ересь. Однако ничего кроме эмоций не предложили.
Я начал думать что я чего то недопонимаю.
Может быть.
Начиная с 70-х я читал слова "концептуальная модель" "инфологическая" "даталогическая". В те времена какой то смысл в этом был. Сейчас я его не вижу. Разве что как средство изложить свои ещё очень сырые соображения.

Vika VinnerНу как бы вы посмотрели на результат ре-факторинга базы данных CRM "Siebel" напрмер конечно отполированной под требования заказчика установленной изначально компанией IBM на некоем предприятии в 30 офисоф по всему шарику - где то 16000 таблиц на DB2 и решивших перевести всё это на Oracle
Хотелось бы посмотреть. Предполагаю, результат был ужасен.

Особо в них восхищает:
авторTNP предназначена для создания программ любой степени сложности.
Пейте данон и вы взойдете.

автору меня подружке муж предложение делал
Вы про своего мужа?

alexeyvg ,
Во первых, неясно кому адресован ваш текст. Видимо не ко мне. Так к кому? Иначе трудно понять кому/чему вы возражаете.
Из Вашего текста создаётся впечатление что Вы совсем не опускаетесь до уровня Management Studio, Enterprise manager, phpMyadmin (я рисую диаграммы баз MySQL в своём базолазе) и иже с ними.
Я ошибаюсь?

Дамы и господа, буду очень благодарен если вы возьмете на себя труд перечислить перечень дополнительных возможностей, которые дают CASE средствоа абстрагированные от СУБД. Доп. возможность должна быть такой что её нет, например, в MS SQL Server Management Studio (или Enterprise Manager, что тоже самое).
Эти доп. features должны относиться именно к проектированию. Не надо трогать средства командной работы, гетерогенность etc. Пока всё что объявлялось плюсом, мне кажется, туда не относится.
То есть призываю к систематизации.
Мне кажется, что приведенные уже аргументы скорее религиозного порядка.

Ну почему же.
В изделии 1 - есть такая то полезная возможность, а в изделии 2 -нет.
Почему бы и не сравнить?

Ну, пусть.
1 -е изделие - Management Studio
Начнем сравнивать?