Да ладно вам дуться друг на друга. На самом деле критерии и понимание того, нужно/не нужно чисто субъективное. Все зависит от используемой концепции. В моей концепции я бы все затолкал в одну базу данных. Поскольку создание новых макрообъектов в ней производится просто триггерами, прицепленных к таблицам метаданных. Имеет ли смысл заводить в новой базе по новому все эти уже наработанные механизмы? Я бы не стал. Ежели нет понятия макрообъектов, нет метаданных, нет связи между данными одной совокупности информации и другой, то можно и разделить по разным таблицам.

Можно к решению разных учетных задач применять схожие способы проектирования. Для чего заводятся объекты или имитации объектов (в терминах объектно-ориентированного программирования), которые находятся на более высоком уровне, нежели объекты SQL-сервера (таблицы, запросы, хранимые процедуры...), поскольку один объект (я называю их МАКРОобъектами) состоит из множества объектов SQL-сервера. Но такие макрообъекты в концептуальном плане ближе к предметной области. Я использую макрообъекты "справочник", "документ", "регистр", "журнал документов". Складывать систему можно из песчинок, можно из кирпичей (покрупнее), а можно из строительных блоков (ну совсем больших). Я предпочитаю последнее.
Я использую таблицы метаданных, в которых хранятся описания макрообъектов и их типы в рамках принятой мной концепции (допускаю, что не для всех случаев жизни она может сгодиться, но для встреченных мной на практике вполне подходит). Операции модификации записей в таблицах метаданных посредством прицепленных к этим таблицам триггеров приводят к появлению "пачками" новых таблиц, представлений и т.д., причем я над их структурой на уровне SQL-сервера даже не задумываюсь - все работает автоматом. Правда, для полноценной объектно-ориентированной модели нужно все это совокупить с аналогичным конструированием на клиенте.
В принципе, унификация, модульность и объектная ориентированность преследует примерно одни цели. Возможно, AlexUnik применил не совсем точный термин, но лично мне его смысл вполне понятен, и я с ним согласен. Может, это несколько неуклюже звучит, но все вместе выше изложенное я понимаю как унифицированный (а точнее, систематизированный) подход к проектированию.

2 Genady. Эта статья во многом устарела, но во второй ее части вкратце описаны принципы построения объектов, о которых я говорил. Начинай читать с главы "О базовой структуре системы, ее объектах и администрировании". Приводить пример справочника слишком объемно - задействованы таблицы и метаданных, и прав доступа, и многого другого (свойств записи, например, до которых недавно дотумкал).

Извини, все рассказал, кроме ссылочки . Вот ссылочка: http://nsa.chat.ru/Raznoe_BigPrgOriginal.html

Я болел, поэтому давно не появлялся.
Повторяю, статья довольно старая. И писал я ее, когда сделать все это пытался в Access на манер а-ля-1С. Однако, отправные точки там обозначены.
А подчеркнуть хочу следующее. Для реализации конкретных бизнес-процессов можно писать приложение, оперируя сразу объектами среды разработки (в данном случае, таблицами, ХП и т.п. SQL server). А можно сделать полуфабрикат. Этакий пластилин-прослойку, из которой далее лепятся бизнес-процессы уже как из объектов, более близких к предметной области. Что называть "программированием"? Разработка пластилина-полуфабриката? Или разработка готового приложения из полуфабриката? В первом варианте всё-в-одном, и такое разделения как таковое отсутствует. Трудоемкость изготовления полуфабриката, а затем приложения из него, конечно, выше, чем просто приложения. НО! . Если структура бизнес-процессов подвержена динамике, то дальнейшее сопровождение жесткого (но быстро спроектированного первым способом) приложения окажется очень трудоемкой. А вот в варианте с полуфабрикатом модификация структуры бизнес-процессов заставляет сосредотачиваться собственно на самих бизнес-процессах и объектах прикладной области, нежели на неувязках в DRI, триггерах, и проч. и проч., которые при модификации около 3000 таблиц нарушаются по уже покрытым забвением причинам.
К примеру, понадобилось создать новые аналитические справочники и завязать на уже существующие регистры или на вновь создаваемые регистры. Я открываю таблицы метаданных и описываю новые макрообъекты. Справочник "Марсианские хроники". Иерархический. Количество уровней иерархии - 6. Поля - такие-то, такого-то типа, ссылается на такие-то справочники. Задаю правила его ведения, нажимаю OK. Срабатывают триггеры на самом SQL-server, которые просматривают сделаные мной изменения структуры метаданных. Появляется автоматом пяток новых таблиц уже с нужными DRI, индексами, констрейнтами и триггерами, десяток SP, несколько VIEW, все это красиво завязывается на уже существующие таблицы. На клиенте вообще все динамически синтезируется по таблицам метаданных. Все! И никаких страданий, синтаксических ошибок, мук с увязкой порядком подзабытых связей и т.п.
Решай сам, что лучше. Если ты просто разработчик, то для тебя, конечно, вариант 1 гораздо лучше во всех отношениях. Во-первых, быстрее и проще. Во-вторых, потом на сопровождении кучу денег можно наскрести на постоянных модификациях жесткого приложения (которые кроме тебя и сделать некому). А если ты постоянно занимаешься подстройкой чужих приложений под свои бизнес-процессы, то тебе будет больше по душе вариант2.
Теперь по пунктам.
1. SQL server суть многопользовательский. Если речь идет об одновременной модификации бизнес-процессов и перечня прикладных макрообъектов с использованием "пластилина" силами нескольких ммм... не программистов даже, а проектировщиков бизнес-процессов (автоматизаторов), так пусть себе на здоровие правят одновременно таблицы метаданных. Никаких проблем!
2. Интересно, сколько времени займет у тебя проектирование голыми средствами SQL-сервера номенклатурного справочника иерархической структуры с механизмом наследования технических характеристик, журнализацией, решением конфликтов репликации (с учетом очень запутанной схемы обмена информацией по множеству филиалов), заданием правил его ведения (чтобы в корень какой-нибудь ухарь не вколотил вместо наименования крупных номенклатурных групп какую-нибудь номенклатурную единицу), разграничением прав доступа на уровне записи, с возможностью иметь разные версии наименования одной номенклатуры в разных учетных периодах (представь, иногда и такое бывает необходимо), с автоматическим проецированием глобальных и номенклатурно-зависимыми связями между единицами измерения (1кг=0.001т=1000г - всегда и везде, 1уп=1000шт - только для "Сникерсов")? Ужели уложишься минут в 15, как при использовании "пластилина"?
3. Описанный в п.2 справочник - это совокупность нескольких таблиц, VIEW, хранимых процедур и многого другого. Допустим, всего в подобный макрообъект входит около 30 объектов SQL-сервера. Как ты полагаешь, что проще - дать права на доступ к "справочнику номенклатуры", или лазить по 30 объектам SQL-сервера и отдельно давать права доступа к каждой таблице, VIEW, хранимой процедуре и т.д., из которых этот объект состоит? В моей практике обычно задействуется около 150 аналитических справочников, 100 регистров, 200 видов документов, 150 отчетов. Это все на порядка 100 пользователей и порядка 10 видов прав доступа = 600000 - уже загнешься раздавать/отнимать права доступа. А помножь все это на 30. Конечно, роли ведение этого хозяйства сильно упрощают. Так я от них и не отказываюсь. Роли и пользователи системы отображаются в роли, логины и юзеров SQL-сервера. И когда я отнимаю доступ у кого-то к справочнику номенклатуры, то выдается залп команд DENY, запрещающих данному юзеру SELECT, UPDATE, INSERT, DELETE, EXECUTE по куче таблиц, вьюшек и хранимых процедур (я даже не задумываюсь, каких). Только кроме этих прав доступа у меня на макрообъектах имеют быть и такие, которых в SQL не предусмотрено. Звучат они так:
"право на просмотр истории модификации"
"право на просмотр версий записи по учетным периодам"
"право на блокировку/разблокировку учетных периодов регистра"
"право на просмотр удаленных записей"
А еще у SQL-сервера "в лоб" не предусмотрено разграничение доступа на уровне записей. Так что ежели это необходимо - то либо ручками, либо кликнуть мышкой по "пластилину" - и готово.
Рассказал много, но ощущаю, что все равно каждый остался при своем мнении

Да, очень много взято именно у 1С, я этого не скрываю. Но в 1С хорошо взяли старт, а потом успокоились. Недоработок тьма, и, похоже, их устранять не собираются. Как и откровенные и грубые ошибки, с которыми оставляю один на один официальных ползователей (я из их числа). Я взял у них полезные идеи, но постарался отбросить имеющиеся у них недостатки. Еще взял несколько идей у "ИНФИН" (они, IMHO, тоже немало полезного напридумывали), у "Паруса", у "ИНФОСОФТ". И добавил собственных (которые вынашивал годами).

Давать и продавать пока нечего. Не готово пока. Нас всего пара человек (да и то, только на протяжении 1.5 месяцев), а до того разработку тащил в одиночку, параллельно занимаясь кучей других вопросов. Иногда был так загружен, что между одной и другой строчкой кода проходили по 2-х месяцев... Сейчас появился просвет. Похоже, руководство дотумкало, что две головы лучше, а руки у человека только две...
На SQL-2000 проект стал делать фактически с нуля и недавно. Прежний под SQL 7.0 (не доделанный)пересмотрен достаточно серьезно. А использование возможностей SQL2K требует новых подходов, и совсем других базовых приемов.
Ради хохмы: в 7.0 ну до того позарез мне нужны были INSTEAD-триггеры, что умудрился сотворить что-то вроде них на простых триггерах с рекурсией и с отслеживанием SPID. Очень похоже работают. Правда, на самом деле это обманка. Чтобы не откатывать транзакцию, я даю выполниться операции, а затем выполняю прямо противоположные действия (аннулирующие исходное действие) - таблица приходит в состояние как в момент старта INSTEAD-триггера. А во вспомогательных таблицах со SPID-полем для решения проблем многопользовательской работы делал имитацию INSERTED и DELETED INSTEAD-триггера. Во, как кувыркаться приходилось! И все равно результаты плачевные - обмануть репликацию не получается. Все обманные телодвижения повторяются в репликации.