bpostЧасто при работе с БД используется технология организации доступа к данным таблиц используя т.н. SUID процедуры
Есть такая глупость.

bpostПриемуществ у этого подхода
Только одно: он наиболее понятен тупому мозгу. В остальном исключительно недостатки. Один из этих недостатков Вы описываете.

2b&2bА с точки зрения построения систем по архитектуре DB <-> AppServer <-> Client ?
Никакой разницы. Точнее, пожалуй, так: если AppServer и так плохо работает с DB, то CRUD-процедуры картину не испортят, в остальном - никакой разницы.

ОдинЕсли смотреть на общее решение работы с базой то тут всплывает фактор "безобразно, зато единообразно"
Согласен, всплывает. В графе "недостатки".

Человек - любопытное существо. Если попробовать заставить его самого пользоваться "безобразным единообразным решением" - например, "ездить на работу на автобусе" - тут же начнется ор:

- А метро быстрее!
- А мерседес круче!
- А мне пешком нравится!

А вот в том, чтобы спроектировать такое "для других" - так он только рад. И плевать, что будут ругаться - главное, что спроектировать и запустить в производство единственный автобус ему проще, чем автобус+мерседес+метро. А уж сейлы отработают свои килобаксы и разведут клиента.

ОдинСейчас у меня в проекте есть некий мэппер, который умеет мэпить объект на параметры ХП. Научить его работать напрямую с таблицами можно, конечно, но зачем ?
Во-первых, Вы в этой фразе предлагаете согласиться с логической ошибкой. "Отказ от тупых процедур" - вовсе не обязательно "напрямую с таблицами", и не стоит приплетать сюда эту "прямую работу" - тут же появятся личности, которые "не умеют готовить" и обсуждение превратится в ликбез на совершенно другую тему.

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

Вы, собственно, предлагаете: если нам нужно применить метод2 или метод3, давайте обернем вызов соответствующего кода в код, соответствующий методу1. Что же в этом хорошего? Ровно одно: обертки, может быть, будет писать кто-то другой. Сложность никуда не девается; просто вместо того, чтобы реализовать ее в одном месте, Вы предлагаете размазать ее по всем местам, где она потребуется. Неизбежно появится дублирование кода (поскольку очень похожие вещи придется реализовывать в куче мест), в самом лучшем случае - сформируется еще некоторое "оберточное API". Эффективность от того не улучшится - конечно, и упадет несильно, но сколько-то ресурсов заберет совершенно напрасно. А самое главное - таким образом мы удалимся от главной цели: легко и просто писать бизнес-функции.

Напомню: цель любого API в том, чтобы позволить программисту реализовывать реально нужные операции "одной строкой". Это позволяет ему сосредоточиться на основном: на бизнес-логике, на том, как из этих операций формируется решение прикладной задачи. Вы по сути говорите: "мне лень сделать это в API, пусть лучше прикладной программист, каждый раз, когда встречает такую проблему, оторвется от нее и напишет некую прокладку вот такого-то вида". С точки зрения идеологии API это просто-таки саботаж.

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

ОдинОднако используя и то и то я не заметил сколь либо серьезных недостатков, равно как и достоинств.
Главный недостаток - никто не будет писать эти обертки. Будут писать тупые процедуры, делающие на порядок больше ввода-вывода, чем нужно, а потом кричать про "сервера БД плохо масштабируются, нужна многозвенка".

ОдинБог с ним, тема не настолько интересная, чтобы пять страниц выяснять кто и что имел ввиду.
"Безобразно, но единообразно" - не достоинство, ни вообще, ни в данном случае.

ОдинВсе что я хотел сказать в данном топике: я не наблюдаю никаких особенных ужасов при использовании действительно не очень красивого подхода "все через ХП"

Хотя теоретически они, ужасы, есть.
Красота - категория абстрактная. Я предпочитаю удобство; если мне нужно что-то сделать, к API один вопрос: "можно сделать" или "надо извращаться".

"Я не наблюдаю" - сами понимаете, флеймово-уязвимая позиция.

ОдинРазнообразие выбора - это не достоинство само по себе.
Согласен. Важную роль в рассмотрении играет "безобразно".

Один комментарий к дальнейшим Вашим рассуждениям - есть разница между "внешним" и "внутренним" взглядом. Одним из достоинств API является возможность сочетать внешнее единообразие, общий интерфейс со внутренним разнообразием, разнообразием реализации. В том, что Вы говорите, неучет этого приводит к некоторой путанице, как мне кажется.

Ну а к сказанному ранее, кстати: Вы предлагали вместо [единообразный интерфейс маппера] - [разнообразные реализации] делать [единообразный интерфейс маппера] - [единообразный интерфейс ХП] - [разнообразные реализации]. Смысла в этом я пока что не вижу, просто лишнее звено.

ОдинНу я считаю, что она честная по крайней мере.
Безусловно. Я просто отметил, что он... неконструктивен, что ли. Если начинать разбирать, уйдем в стандартные флеймы, чего не хочется, а в таком виде.... допустим, Вы скажете: "я не видел слона". Я отвечу: "А я не видел жирафа". И все, поговорили, но пользы с того...

bpost1) Возможность организовать гибкое разделение доступа пользователей к данным.
Процедуры для этого сугубо не обязательны.

bpostЭту задачу можно решить
В том числе способами, которые Вы забыли упомянуть.

bpostПриемущество подходов Б) и В) ..
И не только их...

bpost(Да и вероятность того, что умный/зловредный юзер наберет в ISQL "DELETE FROM tablename" исключается).
Хм. Такое впечатление, что Вы попали в ту самую упомянутую выше логическую ошибку "либо тупые процедуры, либо прямой доступ".

bpost2) Изоляция клиенских приложений от деталей структуры БД.
Процедур совершенно не требует. Впрочем, и само по себе желание - отправдано только с точки зрения сугубых теоретиков.

bpostПришел к выводу, что в UPDATE процедуры придется добавлять дополнительный параметр (BITMASK) с перечнем измененных полей (изменять все не катит).
Плохое решение, имхо, причем со всех точек зрения, начиная с идеологической и кончая сугубой техникой. Для начала Вам придется громоздить этакий генератор sql-я, либо копируя по процедурам прорву очень похожего кода, либо натыкаясь на недостаточность серверного языка для решения этой задачи. Когда справитесь с этой задачей, пойдут проблемы динамического sql.

bpostНе думаю, шаблоны SUID процедур форируются PowerDesigner-ом,
Угу, уже требуется костыль. Все больше тупого кода, все труднее искать и сопровожать "нетупой".

bpostПо поводу остального: разумеется использование SUID - не единственный подход, но это возможный подход для реализации комплексной логики доступа.
Возможный. Но это не синоним "достаточно качественный".

bpost softwarerВ том числе способами, которые Вы забыли упомянуть - ну разумеется :) нельзя объять необъятного (С).
Разумеется. Однако, рассуждения, который Вы приводите сразу после этого, как раз и пытаются заняться этим. Грубо говоря, из факта "один плохой способ лучше другого плохого способа" ничего особенного не следует.

bpostИзоляция звеньев, формальные контракты между ними ....
Простите, у меня нет времени подробно рассказывать о разнице между теорией и практикой. Буквально в два слова: во-первых, СУБД сама по себе является движком высокоуровневых абстракций, таких как view и table function, и они обеспечивают все потребности "изоляции" вкупе с много лучшим качеством других операций. Во-вторых, "изменения", затрагивающие БД, можно разделить на две больших группы, из каждой из которых приведу по примеру:

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

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

В целом, подход "только ХП" не обеспечивает практически более высокой независимости звеньев по сравнению с подходом "разумно использовать DML с клиента".

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, выбирающие из них данные. Предположим, у меня появилась потребность вывести на клиенте следующие данные (и ничего более, например, пользователь захотел видеть на рабочем месте пару новых графиков)


Если бы sp_p и sp_q были вьюхами, я бы спокойно модифицировал только клиента, прописав на нем этот запрос - и тот бы нормально работал. В случае хранимок, которые "сначала выполнят полный запрос, потом будут думать" - производительность будет просто ужасной. Поэтому мне придется лезть на сервер писать на нем новую ХП либо дорабатывать существующие (и где, спрашивается, хваленая Вами изоляция и независимость уровней? Напомню при этом, что вышеупомянутые объекты - части интерфейса, того самого публичного контракта, и клиент, манипулируя ими, ничего не нарушает).

Далее, в случае MSSQL2000 наблюдается большая проблема с динамическим SQL - он выполняется с правами вызывающего. Попробуйте, скажем, решить хранимкой следующую задачу: есть таблица, которая может фильтроваться по десяти полям в разничных комбинациях. Для некоторых полей возможна передача списков значений (для проверки в IN), для строковых сравнение может идти как по '=', так и по 'like', даты могут задаваться либо точным значением, либо диапазоном. Решить ее динамическим SQL Вы не сможете (поскольку для этого потребуется давать пользователю грант на доступ к таблице), придется писать накрученный запрос со смыслом "если задано вот это условие, то фильтровать вот так". Добиваться эффективности от таких запросов - очень тяжелое и малоосмысленное занятие; они будут неудобны в сопровождении и плохи по скорости. А чтобы "добить" Вас - подумайте над задачей "в зависимости от того, задано ли условие фильтрации, нужно подключать либо не подключать в запрос еще одну таблицу".

Итого, в целом мы получаем следующее: мы не имеем возможности эффективно манипулировать данными из хранимок ни снаружи (после их вызова), ни внутри (передавая ограничения как параметры). Из чего следует вывод: единственный путь работать эффективно - делать по хранимке на каждый запрос, который только есть в клиенте. Что убивает ту самую независимость, которой мы пытаемся достичь! Сервер с клиентом оказываются связанными аки симские близнецы, можно уверенно сказать, что почти любая модификация потребует изменений во всех компонентах системы. Надеюсь, не надо объяснять, чем это плохо.

О динамическом SQL в интербейсе я знаю очень мало, даже не знаю, есть ли он :)

В общем скажу так: насколько я знаю, в плане решения "возврата датасетов из ХП" Oracle, с которым я работаю, заметно превосходит и MSSQL2000, и Interbase. Но даже при этом - практика остается плохой, хуже чем view.

Если говорить о недостатках view - они есть, но не превосходят недостатков ХП.

iscrafmинтересно каким образом? AS обеспечивает централизованный доступ к БД. Это 1 пользователь.
Именно. Поэтому любая дырка в AS и любой путь мимо AS - это ЧП высшей категории, "злоумышленник получил полный доступ".

iscrafmЕсли в базу кто-то лазит мимо AS, то разбираетесь с доступом.
Ну да, ну да. Уже хорошо видно, как "AS элементарно решает эту задачу".

iscrafmИ зачем что-то открывать для генератора отчетов, если он тоже "ходит" через AS?
Плюньте в лицо тому, кто Вам сказал такую глупость.

Впрочем, с любопытством понаблюдаю, как Вы объясните например Oracle Discoverer-у, что он должен ходить к данным через ваш AS.

iscrafmно при этом ругаете трехзвенку, в которой подобные задачи решаются элементарно. Трехзвенок что-ли не видели?
Не видел, писал. И потому рассказы про "элементарно" вызывают нездоровый смех, примерно такой же, какой ранее вызывали аналогичные рассказы "а наш клиент всегда логинится под одним пользователем, а права проверяет внутри себя".

MasterZivМы организуем их как логические операции в терминах предметной области.
Я бы только отметил, что именно поэтому это не SUID-процедуры. Не тупой автоматический код, а "умные" операции, отвечающие постановке задачи.

iscrafmмного наговорили, только о чем - непонятно.
Подумайте, может и поймете.

iscrafmЕсли DBA дает доступ кому-то кроме сервера приложений,
Не, не поймете.

iscrafmкак здесь принято говорить, "пад сталом" Не могу плюнуть себе в лицо, извините уж. Не обладаю необходимой пластикой.
Попросите коллег помочь, раз уж не можете решить элементарную задачу в одиночку. Хотя тоже показатель инженерного мастерства. Прямо таки "чего думать - гнуться надо".

iscrafmА Вам для иллюстрации, каким образом отчетные системы ходят через сервер приложений к СУБД . Может ролику поверите, а то все словам чьим-то :).
Ну и где там Oracle Discoverer? Правда, не уверен, что ваш ролик работает до конца - у меня он останавливается вот на этом кадре



который как-то черезчур сбоен для финального, но то, что там показано, более похоже на неубедительную самоделку с экспортом.

iscrafmsoftwarer, Ваши высказывания уже вызывают нездоровый смех.
Не удивлен, это довольно типичная реакция на знания другого уровня. Скажем, если Вы подойдете к дипломированному чернорабочему и скажете, что "ботаник" с помощью пары-другой блоков поднимет шестипудовый мешок цемента - тот тоже, вполне вероятно, будет хохотать.

iscrafmНе раз говорилось, что если у Вас не получилось по каким-то причинам сделать трехзвенку,
Говорилось? И отчего же тогда только в прошлом письме Вы спрашивали про мой опыт? Временно забыли?

iscrafmто это не повод при любом упоминании о ней кривиться и кричать "must die".
Поскольку это не первая косвенная ложь, которую Вы допустили в этом топике, предпочту ткнуть Вас носом: будьте так добры, покажите, где я при упоминании в этом топике "кричал must die" либо же публично принести извинения за ложь.

bpost BelyСУБД Oracle, FGAC
Да, это вешчь :). Но денег наверное стоит немеряно (как сама СУБД, так и минимально приемлимое оборудование ее эксплуатации). Да и входит ли Oracle Label Security в стандартный набор расширений ?
Во-первых, не стоит путать FGAC и Label Security, это разные вещи. Во-вторых, насчет минимально приемлимого оборудования.... скажем так, пару лет назад одним из серверов моего (тогда) отдела был гигагерцовый целерон с 256 Мб памяти.

bpostПринимается. Наверно будет удобнее решить ту же задачу используя представления + INSTED OF триггеры. Но все равно - прощай индексы в JOINах.
instead - уже не обязательно, обновление вполне неплохо идет и через ХП, я здесь предпочитаю подход, озвученный MasterZiv . Возможность instead of конечно, можно использовать. Насчет индексов - не очень понял, наверное какая-нибудь конкретная ситуация, но скажу так: у вьюх как минимум есть шанс на оптимизацию "запроса в целом", а у независимо выполняемых запросов - ни малейшего.

iscrafmтам его нет, интерфейс к нему не включен в список
Уже что-то. Итак, эксперимент с попыткой подключиться генератором отчетов к вашим данным показал, что AS тут не помощник. Что, собственно, уже доказывает то мое исходное утверждение, на которое Вы пытались возразить. Мало того, ни одного генератора отчетов в списке я не заметил (если Вы про тот список, который от сводной таблицы через FastReport до Excel). Если про другой, прошу дать более точные координаты, например ключевое слово для поиска.

Что касается следующего эксперимента - ответа на вопрос "а по силам ли вам разработать интерфейс для подключения Discoverer, сколько это будет стоить и сможет ли работать с требуемыми объемами данных" - если хотите, попробуйте ответить, но я и так не особо сомневаюсь в результате.

iscrafmА еще там нет Crystal-а, досадааа!
С точки зрения Вашей аргументации - безусловно. Итак, Discoverer - это уже даже не разовый эффект, "только к нему и нет". Итого, если я сижу с генератором отчетов и хочу работать с вашими данными, ваш AS вместе с его механизмами RLS идет лесом, я правильно излагаю?

iscrafm softwarerкоторый как-то черезчур сбоен для финального, но то, что там показано, более похоже на неубедительную самоделку с экспортом.
Это о чем вообще, разговор поддержать? Кто сбоен и какой экспорт? Сами то поняли?
Не юродствуйте, судя по уровню, который Вы демонстрируете в разговоре, понимание этой фразы не должно вызывать у Вас проблем. На всякий случай проясню по пунктам.

"Кадр, который черезчур сбоен" - неужели этого недостаточно, чтобы ответить на вопрос "кто сбоен"? Поясняю: кадр. То изображение, которое приведено в сделанном мной снапшоте.

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

iscrafmтак повышайте уровень, в чем проблема?
Так повышаю, проблем нет. В качестве побочного эффекта - по мере повышения все чаще звучит нездоровый смех.

Да, кстати, я бы советовал вам поправить грамматическую ошибку во фразе " Запуск из web-страниц и flas-презентаций (iconsole://rundocument) " (и на будущее - настоятельно рекомендую прогонять тексты через проверку правописания) и учесть, что при просмотре в FireFox после этой строчки виден двойной промежуток (если мне не изменяет память, это одна из особенностей FireFox после <li>.

iscrafmне забыл, поэтому и интересуюсь, на основании чего вы делаете множество пространных высказываний.
Хотите интересоваться - задавайте прямые вопросы, это эффективнее. А то заходите издалека, после чего жалуетесь на ответы.

iscrafmИзвините, дословно "must die" не кричали.
Дословно - принято, теперь, в продолжение темы про Гильчиперчика, будьте так добры показать, где кричал не дословно, на аналогичных условиях.

ChAПоправлю, в MSSQL есть 2 вида табличных функций: inline - это то, о чем Вы упомянули выше, и multistatement, который также возвращает выборку, но логика внутри может быть почти такой же сложной, как в ХП. И может быть включена в запрос также, как и любая другая таблица. Именно в этом смысле функции называются табличными. Если нетрудно, можете озвучить Ваш вариант определения табличных функций ?
Спасибо за уточнение, насколько я понимаю, это вопрос больше неточности моей терминологии. В моем представлении, "табличная функция - это функция, которая вычисляет и возвращает таблицу". Подчеркну, именно "вычисляет" - и в этом смысле, насколько я понимаю, это соответствует multistatement table function.

Я подчеркиваю принципиальную разницу этого варианта с вариантом inline, в котором возвращается не таблица, а "запрос". Механизм действия этих "функций" очень сходен с механизмом view, практически это "view с параметрами" и с моей точки зрения, так их и стоит называть - parametrized view. По крайней мере, если я правильно понимаю механику реализации этих функций в MSSQL.

ChA softwarerДалее, в случае MSSQL2000 наблюдается большая проблема с динамическим SQL - он выполняется с правами вызывающего.Может уже пора забывать о 2000 ?
Простите великодушно, но мой собеседник, ставя задачу, настаивал именно на 2000. Полагаете, с моей стороны было бы корректно забыть об этом? Более того, настаивал он не просто так, а чтобы отключить упоминания об RLS средствами СУБД - и мне кажется, было бы странно забыть об одном ликвидированном недостатке 2000-го и при этом не забывать о другом.

iscrafmБред какой-то. Я не понимаю таких "высоких" мыслей.
Слив номер раз (в этом посте). Но Вам стоило сделать это раньше, до того, как Вы сказали "не умеем".

iscrafmя на вскидку не отвечаю на такие вопросы. Не могу сказать, сколько это будет стоить, по той простой причине что не помню какие интерфейсы предоставляет OD. надеюсь понятно.
Я же сказал, что не особо сомневаюсь в ответе. Впрочем, если таки хотите попробовать - меня вполне устроит качественная характеристика, например

- бесплатно
- вряд ли больше $500
- скорее всего, от $500 до $5'000
- скорее всего, от $5'000 до $50'000
- ....

Напомню, в вопрос также входит эффективность работы получившегося отчета.

iscrafmмда... Ладно, скажу так: мы не производим ПО для создания демороликов.
Не стоит уводить разговор в сторону, а если пытаетесь, не стоит так грубо. Сбой упомянут только потому, что у меня было уверенности в том, что воспроизведение не обрывается на середине (а где-то дальше показано то взаимодействие, которое меня интересует).

iscrafmЕсли оно вам кажется сбойным, то давайте обсудим, какие есть хорошие несбойные утилиты для создания демороликов.
Не особо разбираюсь. Лично меня полностью устраивал HyperCam, но с этим Вам скорее всего в другой форум и к другим людям.

iscrafmНе знаю про какой экспорт вы продолжаете упорно твердить, но попробую догадаться.
Уже прогресс. Потом попробуйте прочитать и понять.

iscrafmНаверное про слова "Экспорт в Excel".. угадал?
Не только. Слова "Форма представления"..."Сводная таблица"..."Окончательная настройка формы представления" (или как там, не помню точно) очень похожи на внутренний генератор отчетов и совершенно не похожи на интерфейс внешнего генератора. Кроме меня, это отметили уже два человека, одному из которых Вы ответили демагогией.

iscrafmИнтерфейс - это, например, когда генератору отчета передается на вход указание на набор данных, который он должен отработать.
Ну.... плохое определение, но если не углубляться, можно принять и так.

iscrafmага, спасибо. обращу внимание. Наконец что-то дельное.
Учитывая, что не в первый и даже не во второй раз - пора брать деньги :)