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 с клиента".