Я говорю о базах MSSQL сервера до версии 2005.
softwarerНасколько я понимаю, Вы говорите о "базах данных" в mssql-ном смысле, аналоге ораклового "схема". Базы в mssql-ном смысле (во всяком случае до версии 2005) это не аналоги оракловских схем. Если я правильно понимаю (поправьте), между таблицами находямися в разных оракловских схемах можно поставить внешний ключ. Между таблицами в разных базах MSSQL нельзя. Есть и другие ограничения.
PVPТо же самое, что и с одной процедурой, если программирование всех новых задач делать в ней одной, где нибудь в средине, вместо того, что бы делать новые процедуры для новых задач. Вы считаете что разрастание кода процедуры и количества объектов базы суть одно и тоже ?
PVPПринцип модульнусти Вы признаете только в автомобилестроении? Или еще и в разработке процедур? Может следует распространить его и базы данных? Что в вашем понимании принцип модульности и чем именно он нарушается, когда объекты, относящиеся к разным, но частично пересекающимся предметным областям находятся в одной БД ? Поясните пожалуйста также почему вы не усматриваете нарушения "принципа модульности" в том, что эти базы находятся в одном сервере БД.

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

LSV авторА вот теперь интересно обсудить плюс/минус хранения "персональных" данных отдельных приложений в одной БД или в различных.Что такое персональные данные ? Где грань между персональным и общим (с учётом того, что логика системы постоянно дорабатывается, перегруппируется, дополняется) ????

Система должна иметь стратегию развития. Универсальной стратегии не существует.
Предложенная Вами стратегия имеет массу недостатков,т.к. модульность не панацея.

Хранение данных в разных БД может быть оправдано:
1. При больших объёмах. Прошлые периоды лежат отдельно и нужны редко
2. Высокие требования по безопасности
3. Наличие коробочных систем, вмешаться в работу которых проблематично
4. Наличие мощного OLAP-анализа (пересекается с п.1). Поддерживаю

PVPЭто не компромис. Это уход выдвинутой идеи. Здесь нарушается принцип модульности. К этой общей базе Вам придется обращаться за доработками каждый раз, когда делаете новую задачу. Потому что в новой задаче будет или справочник, или еще что нибудь такое, чего не было в предыдущих. Попробуйте поработать в этом же направлении, только в не делая отдельную специальную базу. Для этого у Вас в каждой базе может быть блок, отвечающий за справочники. Он одинавый для всех задач. Процедуры для работы с ним, а также форма (формы) клиентского модуля также одинаковы. Зачем тогда справочники сбрасывать в одну общую базу? Действительно, лучше для каждой задачи поддерживать свой набор справочников. Актуальных. Главное не забывать вовремя вносить изменения.
PVPОговорюсь, на всякий случай. Я далек от того, что принцип модульности можно выполнить на все сто процентов. Это как в одном анегдоте - все не выйдет, но стремиться к этому следует. Продолжая вашу аналогию с автомобилестроением - почему в автомобиле только один аккумулятор ? Не лучше ли сделать у каждого агрегата свой. Ну чтобы "модульность" не нарушалась.

PVPА разве во всех автомобилях только один аккумулятор? Не ужели нет таких, где для разных узлов есть отдельные? Например в электромобилях. Я бы поставил отдельный для сигнализации, например, в запорожце. Общий отключил, потому что там замок зажигания не надежен, а дополнительный передает мне сигнал, когда кто то пытается угнать машину. Вот именно, _иногда_ есть и несколько аккумуляторов, но как я понял из ваших слов PVPЯ далек от того, что принцип модульности можно выполнить на все сто процентов. Это как в одном анегдоте - все не выйдет, но стремиться к этому следует. надо стремиться к тому, чтобы у каждого узла, в котором используется электричество был свой. Есть еще куда развиваться конструкторской мысли :)

MasterZivНо тут нельзя увлекаться, надо четко разграничить, что можно и нужно делать через универсальный интерфейс, а что нельзя. Например, нельзя писать самоконфигурируемые формы которые могут по данным себя конфигурировать и все на свете редактировать. Легче, проще и надежнее , и эффективнее в смысле эргономики GUI, написать это в лоб, явным образом, как обычную форму.

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