bpostРешение с использованием промежуточного AS оставим за скобками (тут все понятно).
В том числе то, что оно часто убивает на корню решение этой задачи, позволяя спокойно забраться в базу мимо AS и более того, прямо-таки требуя открыть такой путь - например, для подключения генераторов отчетов.
bpostСУБД: MS Sql Server 2000 или Interbase/Firebird (на выбор). Как бы Вы решили эту задачу средствами СУБД, и чем Ваше решение принципиально отличается в лучшую сторону от SUID подхода ?
К сожалению, по-прежнему нет времени на подробный ответ, кратко: решил бы средствами "именованных запросов на сервере", то есть view для любых серверов и/или того, что в MSSQL называется table function (как всегда, они проявили умение выбрать название, совершенно не соответствующее сути, но "маркетинговое". Обратите внимание, я не отношу table function к "ХП", поскольку общего между ними - что между рыбой и сковородкой. Table function - это "параметризованный view").
Общий недостаток ХП-решений по сравнению с этим подходом - они не могут хорошо участвовать в дальнейших SQL-манипуляциях. Скажем, допустим, у меня есть таблицы tab_p и tab_q, а также хранимки sp_p и sp_q, выбирающие из них данные. Предположим, у меня появилась потребность вывести на клиенте следующие данные (и ничего более, например, пользователь захотел видеть на рабочем месте пару новых графиков)
1.
2.
select p.*, q.* from sp_p p, sp_q q where p.id = q.id
select p.* from sp_p where date_start >= trunc (current_date, 'MM') and location_id = :location_id
Если бы sp_p и sp_q были вьюхами, я бы спокойно модифицировал только клиента, прописав на нем этот запрос - и тот бы нормально работал. В случае хранимок, которые "сначала выполнят полный запрос, потом будут думать" - производительность будет просто ужасной. Поэтому мне придется лезть на сервер писать на нем новую ХП либо дорабатывать существующие (и где, спрашивается, хваленая Вами изоляция и независимость уровней? Напомню при этом, что вышеупомянутые объекты - части интерфейса, того самого публичного контракта, и клиент, манипулируя ими, ничего не нарушает).
Далее, в случае MSSQL2000 наблюдается большая проблема с динамическим SQL - он выполняется с правами вызывающего. Попробуйте, скажем, решить хранимкой следующую задачу: есть таблица, которая может фильтроваться по десяти полям в разничных комбинациях. Для некоторых полей возможна передача списков значений (для проверки в IN), для строковых сравнение может идти как по '=', так и по 'like', даты могут задаваться либо точным значением, либо диапазоном. Решить ее динамическим SQL Вы не сможете (поскольку для этого потребуется давать пользователю грант на доступ к таблице), придется писать накрученный запрос со смыслом "если задано вот это условие, то фильтровать вот так". Добиваться эффективности от таких запросов - очень тяжелое и малоосмысленное занятие; они будут неудобны в сопровождении и плохи по скорости. А чтобы "добить" Вас - подумайте над задачей "в зависимости от того, задано ли условие фильтрации, нужно подключать либо не подключать в запрос еще одну таблицу".
Итого, в целом мы получаем следующее: мы не имеем возможности эффективно манипулировать данными из хранимок ни снаружи (после их вызова), ни внутри (передавая ограничения как параметры). Из чего следует вывод: единственный путь работать эффективно - делать по хранимке на каждый запрос, который только есть в клиенте. Что убивает ту самую независимость, которой мы пытаемся достичь! Сервер с клиентом оказываются связанными аки симские близнецы, можно уверенно сказать, что почти любая модификация потребует изменений во всех компонентах системы. Надеюсь, не надо объяснять, чем это плохо.
О динамическом SQL в интербейсе я знаю очень мало, даже не знаю, есть ли он :)
В общем скажу так: насколько я знаю, в плане решения "возврата датасетов из ХП" Oracle, с которым я работаю, заметно превосходит и MSSQL2000, и Interbase. Но даже при этом - практика остается плохой, хуже чем view.
Если говорить о недостатках view - они есть, но не превосходят недостатков ХП.
