Есть такой проект, более 250 таблиц. А также большое количество VIEW и хранимых процедур. При проектирвании не использовалось никаких CASE-средств, только SQL-скрипты. Всё живёт и работает уже четвёртый год.
Но справедливости ради следует отметить следующее.
1) База данных была поделена на на части и всю эту прорву таблиц, view и процедур разрабатывало несколько человек, каждый отвечал за свою группу объектов. Один человек просто физически не может проектировать сложную предметную область и отслеживать её изменения в БД.
2) Разработчики не использовали CASE-средства для создания объектов, но довольно часто для анализа взаимосвязей между таблицами и для наглядности они пользовались средствами графического представления структуры БД по сущетсвуюей базе. В частности, средствами, входящим в SQL Enterprise Manager и Visio 5
3) Клиентских программ, которые работают с этой базой данных, довольно много, не менее десяти.
4) Были попытки использовать Power Designor 5.0 с MS SQL 6.5 ещё в самом начале работы. Но было столько глюков, что пришлось отказаться от его использования. То он некоторых CHECK-ов не видел, то UNIQUE constraints зачем-то превращал в уникальные индексы (CREATE INDEX). Вобщем, проблем было больше, чем пользы. А SQL 7.0 появилось своё средство для построения диаграмм, т.к. вроде использование CASE-средств оказалось не нужным.

Добавлю ещё, что по моему мнению, проектировщики делятся на две большие группы по своему отношению к CASE-средстам.

Одни их используют на всем этапе, от создания объектов БД до модификации и документирования.

Другие предпочитают создавать объекты в БД напрямую, SQL-скриптами. И относятся к SQL-скриптам как к такой-же части программного обеспечения, как скажем программы на Delphi, С++ или VB. Разработчик, который способен контролировать клиентский проект из нескольких тысяч строк, обычно может контролировать и комментировать SQL-скрипты, объём которых как правило меньше, чем объём клиентских приложений.
Но и эта группа разработчиков использует CASE-средства, правда только для графической визуализации. Для понимания и чтобы можно было повесить на стенку или приложить к документации, особенно это полезно когда другой разработчик пытается понять схему, которую спроектировал его коллега.

Я не берусь утверждать, что какой-то из этих способов хуже или лучше. У обоих есть свои плюсы и минусы.