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

Можно к решению разных учетных задач применять схожие способы проектирования. Для чего заводятся объекты или имитации объектов (в терминах объектно-ориентированного программирования), которые находятся на более высоком уровне, нежели объекты 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-триггера. Во, как кувыркаться приходилось! И все равно результаты плачевные - обмануть репликацию не получается. Все обманные телодвижения повторяются в репликации.

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

2Genady. Вы тоже все правильно поняли. За одним ну очень небольшим нюансом:
>надстройка над реляционной схемой данных, которую он пытается решить средствами самой реляционной СУБД (что по моему ему не очень удается, поскольку он оговорился, что для нормальной реализации, клиента все равно трогать приходится).
Да, пока система не доделана, это приходится делать. Но в до конца доделанной системе в этом нет необходимости. Если интерфейс унифицированный для каждого вида макрообъекта(состав панели инструментов, единообразный подход в построении экранных форм макрообъектов одного вида), и в таблицах метаданных хранятся параметры отображения на экране (размеры, положение на форме, цвет шрифта, и т.д.), то визуализация макрообъекта на клиенте производится с помощью динамического формирования экземпляра соответствующего класса.

Расплачиваться приходится всегда и за все. Время загрузки формы, конечно, увеличивается. Только большооо-ооой триггер к этому отношения не имеет. Этот триггер пересчитывает псевдорекурисвным алгоритмом права доступа ко всем объектам при всех ситуациях, которые могут повлиять на права доступа (добавление/удаление ролей, изменение членства в ролях, изменение прав доступа к объектам ролей и т.п.)