Доброго времени суток. Вопрос: спроектировали БД, где для нахождения одной из сущностей требуется произвести 48 объединений(остальные гораздо меньше ~4-8), это в первую очередь связано с наличием многочисленных адресов, а также ссылками из этой сущности на др. сущности, которые содержат ссылки опять же на сущность "Адреса"(КЛАДР). В целом что бы вытянуть запись или фильтрануть все экземпляры сущности надо построить дикой запрос, отрабатывать который СУБД отказывается. Есть ли технологии в проектирование, которые позволяют доразбить сущности. Думал, что можно отрабатывать отдельно записи основной сущности и отдельно те на которые ссылается основная, а далее произвести объединение в ручную, но вроде как это должна делать СУБД. Может у кого есть опыт в подобных вопросах.

АнатоЛой, Мне нужно конкретное решение для СУБД ЛИНТЕР, да в принципе та же проблема и в MySQL - потому решение в одной из них подойдет и для другой. Возможно что есть решение и на уровне теории. Ну там как разделить сущность и пр. ТОлько вот с разделением не понятно: как потом фильтровать и пр. - опять придется объединять. Вот и получается, что ходим по замкнутому кругу.

mcureenab, Дело в том что запрос отрабатывается на одно подключение пользователя, следующий запрос - это новое подключение, а стало быть и view пролетает

АнатоЛой, Это не совсем бред. View создается для пользователя с конкретными правами, он имеет доступ к 10 таблицам из 20 и объединение для него одно(view), другой с другими правами и в результате получаем некоторое множество объединений на одну и туже сущность, что согласитесь затратно будет. Ну да если выбрать view то схема такая получается: сначала строим view на основе 10 первых объединений, а потом достраиваем оставшиеся к нему объединения в несколько этапов. Но вот ведь незадача: представление – это таблица-результат выполнения <запроса выборки>.
«Материализация» представления осуществляется СУБД каждый раз при выполнении запроса, в котором имеется ссылка на представление. Получается вроде как спасительное представление вновь вытягивается в мега запрос.
Переработать схему тоже не выход, сущность определена в соответствие с требованиями нормативных документов. Другое дело - отработать не все поля, а соответственно и не все объединения. Косяк в этом случае возникнет если пользователь захочет фильтрануть по всем полям - вот тогда потребуются все объединения(вероятность не велика ~2%). Для примера простая схемка.
Есть сущность "Персона" у нее имеется ссылочное поле на сущность "Адрес" (проживания\прописки), которое представляет собой КлАдр; ссылочное поле на сущность "Работа". В сущности работа есть ссылочное поле "Адрес"(рег. юр. лица) и многие др. ссылочные поля. Соответственно, когда пользователь захочет посмотреть экземпляр сущности "Персона", то она потянет за собой и все ссылочные поля сущности "Работа"(ну как например узнать всех персон, работающих по улице "Жданова"). Да как видно нельзя просто взять и объединить поля различных сущностей для простоты работы, например с "Персоной".

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

Бредятина, Можно уточнить как это ссылочное поле превращается в связь 1:1. Например есть сущности "Персона" и "Работа". В "Персона" есть ссылочное поле на "Работа". При этом один экземпляр сущности "Работа" может принадлежать множеству экземпляров сущности "Персона". Так как же тут без join обойтися. Подскажите, может где подробно написано, как это круто сделано(ну круче чем в 1С), может даже исходники есть. Сейчас важна любая информация. Спасибо