Один из принципов эффективного управления сложными структурами - разбиения однородного месива на наборы более и менее взаимосвязанных кластеров - пакетов, пространств имён и т.д. Такой подход активно применяется при проектировании системы вцелом, а также функциональных и объектных приложений.

Есть ли какие-то подходы для аналогичной операции применительно к базам данных? На уровне МОДЕЛЕЙ инструменты проектирования (CASE-tools) позволяют выделять domain areas, packages, но при переходе на уровень реализации (DB IDE) мы получаем линейный список таблиц . При работе с линейным списком проблемы обычно такого рода:
1) Трудно быстро найти нужный объект, или убедиться в его отсутствии (у меня 400 таблиц);
2) Трудно ручным и программным образом выделить подмножество объектов, которые должны быть обработаны;
3) Различные сегменты БД могут иметь различные требования по безопасности - а вручную назначать каждый объект на конкретного системного пользователя БД не очень удобно;
4) Трудно увидеть взаимосвязанные объекты, и наличие - отсутствие связей, соответственно.

Соображения такие - стоит каким-то образом отделять БД предметной области от БД приложения. Это повысит управляемость (проще оперировать 20 + 80 таблицами, чем 100), а также, потенциально, безопасность, т.к. к этим базам обычно применимы различные критерии уязвимости + возможно различные критерии строгости данных. Например, в БД приложения все внешние ключи должны существовать, а в БД предметной области могут существовать более мягкие условия.

Далее, можно разбивать внутри пакеты таблиц приложения и пакета таблиц предметной области на более мелкие пакеты, если это имеет смысл.

Пока мне приходят в голову следующие варианты:
1) Разнесение по разным схемам БД.
2) Введение префиксов.
3) Иерахическое представление набора таблиц, где в качестве корневых элементов выступают таблицы, имеющие минимальное количество исходящих ссылок.
4) Полная интеграция средства моделирования и средства рабработки БД (Управление через модель не только структурой, но и данными).

В данных момент мне наиболее интересным в смысле практической быстрой реализуемости представляется подход 1. Если у вас опыт применения подобного подхода? По крайней мере SQL 2000 жалуется, что создавать ключи на таблицы в других схемах не может, а это достаточно полезно.

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

но повторюсь: словарь системы необходим, хотя бы с точки зрения вертикального контроля доступа (на уровне атрибутов)Что такое "вертикальный контроль доступа"? Гугль такого не знает. Словарь системы не решает проблему эффективной навигации по объектам БД средствами IDE.

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

Но факт управления 100 таблицами меня не пугает: запросы пока строят ручками, а не супер-умным автогенератором, поэтому для этого словарь применять пмсм не очень удачно (все равно хинты и прочее руками дописывать) - может быть это и не правильно, собственно в любом промышленном отчетнике на основе словаря (юниверса) отчеты строятся.
Я рассматриваю интересы не только программиста SQL-запросов, но и администратора БД и архитектора/проектировщика БД, отвечающего за "робастность" схемы. Хорошо, допустим мы разделили список таблиц по различным предметным областям с помощью префиксов, получили в каждой, скажем, по 30 таблиц. Типичный браузер объектов покажет их списком - т.е. придётся глазами искать нужную таблицу по имени. Но о их взаимосвязях можно узнать только отдельно просмотрев ключи или построив диаграмму каким-либо образом. Идея с иерархическим навигатором состоит в том, чтобы по возможности показывать дерево, начиная с самых независимых таблиц (на основе внешних ключей). Как минимум, чтобы справочники, которые используются только для одной таблицы, не показывались на первом уровне, а являлись подузлами для неё. Это ускорит доступ к таблицам с данными + повысит уровень понимания схемы тем, кто этот браузер будет использовать. Плюс будет автоматически решаться задача аудита несвязанных таблиц.

Плюсов полно. По поводу интеграции case-у меня pd генерит практически все данные для словаря системы (оо-модель бизнес-сущностей в нем, словарь системы - в бд, данные загоняются туда скриптом). минусы - его еще надо пасти (я пасу pd) либо руками, либо утилитой своей или чужой.SQL-программист и зачастую админ работают с базой не через CASE, а через IDE. Я говорил про другую интеграцию - чтобы IDE и CASE сливались в единый инструмент, который позволит вести разработку в единой среде.

Блин,какое умное название темы. Прямо чувствуешь свою ущербность."Вертикальный контроль доступа" не хуже.