Внутри первого вьювера DOC_TYPE_NAME тоже в таблице с алисом d находится или другой ?

Ex_Soft
Это все - хорошо... А по сути вопроса?

По сути вопроса делайте 2 плана с vD.DOC_FULL и без него. Я правда не силен в оптимизаторе АСЕ, но вот в АСА встречался с такой вещью - оптимизатор брал все вьюверы, разворачивал их в запрос, убирал таблицы, на которых нет ссылок и с которых не берутся столбцы и в зависимости от того, что ставил в SELECT, результаты мягко говоря разнились. Поэтому сравните 2 плана - идентичны они или нет и доложите сюда о результатах.

Ex_SoftКакие будут у кого идеи/мЫсли/предложения?
У меня давным давно сформировалась мысль в отношении проектирования БД - не делать сложные вьюхи, ссылающиеся друг на друга. Поэтому как свое предложение - перепешите вью так, чтобы он не ссылался на другие, причем не просто вставив текстом подзапрос вместо используемого вьювера, а напишите его с нуля, то есть оптимизировав.

Ex_Soft
ASCRUS
перепешите

Сегодня встал спозаранку, обуреваемый такой же мыслью. Но как посмотрел в скольких местах это все хозяйство юзается - творческий энтузизим пропал напрочЪ Ж8-/
_________________
"Helo, word!" - 17 errors 56 warnings

Ну так вложенные вьюверы оставьте и не трогайте. Перепишите только верхний, сделав только нужное кол-во соединений и исключив подзапросы. Тогда все Ваше хозяйство и будет продолжать работать как обычно.

Ex_Soft
ASCRUS
Ну так вложенные вьюверы оставьте и не трогайте. Перепишите только верхний

Ну, дык, view, как раз, и создавались, чтобы в тысячи местах не писать одно и тоже. Сами по себе они, практически, пользы и применения не имеют. Просто брались common'овский, часто повторяемые join'ы и оформлялись в виде view. IMHO, я так понимаю, одно из основных предназначений view, как раз, в этом - воплотить в себе часто используемые запросы/части запросов.
_________________
"Helo, word!" - 17 errors 56 warnings

В моем представлении view это оформление некой физической модели сущностей БД в логическую, то есть некий слой, соединяющий физические сущности и представляющий их в виде логических. Как повторно используемый код view плохо выглядят хотя бы из за того, что при использовании из view других view, мы в итоге имеем подзапросы и повышенную нагрузку на оптимизатор и сервер. Все таки я считаю, что запросы должны писаться оптимизированными, а не собираться с тучи унифицированных подзапросов. Например, в Вашем случае, легче наверное было бы сделать вычисляемое поле DOC_FULL в таблице, из за которого не пришлось бы в итоге писать вью и организовывать вложенность вьюверов. Если Вы хотите выделять логическое представление данных, специально подготовленное для клиентской или отчетной части, то для этого мне кажется гораздо перспективнее использовать ХП, в которых для сложной обработки данных можно задействовать те же временные таблицы. Вообще IMHO РСУБД не любят унификации на уровне повторно используемого кода, даже вложенность ХП или использование UDF уже серьезно снижает производительность. Поэтому, в случаях, когда приходится писать один и тот же код, я предпочитаю использовать метод паттернов - например вместо того, чтобы обеспечить некую централизованную обработку проверки из всех триггеров БД, я не пишу супер пупер ХП, которая вызывается со всех триггеров и в ней для обработки пытаются получиться все доступные поля в триггере, а пишу шаблон генерации триггера с параметрами имени таблицы в ISQL и просто запускаю его там, указывая имя таблицы, на которою нужно сгенерить триггер.