Stored procedures security

[singalen]

ru_sql пока меня не пускает, ru_case сдох из-за неправильного названия.
Вопрошу у себя: какие именно угрозы безопасности закрывает DAL на stored procedures, в отличие от динамического SQL, как, скажем, в Hibernate? (уточнение вопроса)
Обычно на них упирают в MS SQL Server, но это потому что оный крив исторически. Даже в версии 2000 не было приличного кэша распарсенных запросов и execution plan-ов (это написано в доке, английским по белому). В результате CRUD на SQL в нём работал раз в 20 медленнее, чем на процедурах. Я не преувеличиваю, а скорее преуменьшаю.
Это приводило даже к таким невероятно уродливым костылям: ODBC драйвера для CRUD каждой таблицы генерировали-компилировали "временные процедуры".
И это в системе, которая называется SQL server. Ещё раз: MS SQL Server 2000 не является полноценным SQL-сервером (поправка).
Даже сейчас мы работаем с ним через кодогенератор (читай - дублируем код в промышленных масштабах).
Не говоря о невероятной кривизне инсталляции 2005-го и затруднениях в администрировании.
И ведь этот вторичный продукт покупают.

Но я хотел поговорить о процедурах как о подходе, не о MS SQL. Какой, в ухо, sql injection, если всё общение - между application server и db server? Нет такой буквы.
Далее, fine-grained security, да. Наверняка более мелкозернистая, чем при распределении доступа к столбцам и строкам. Но зачем она нам? Ищу и не нахожу ответа. Обычно всё равно приходится реализовывать более-менее полнофункциональный API для каждой сущности - получить список, получить по ключу, записать, удалить. В результате security не более fine-grained, чем на таблицах/столбцах.
Не говорите мне о вынесении бизнес-логики на уровень сервера БД. Ни один из известных мне популярных языков хранимых процедур не приспособлен для более-менее приличного программирования, у них ужасный синтаксис и никакие отладчики. Исключение, может быть, составляют встраиваемые в PostgreSQL языки, и оракловая Джава. Но и тут я не уверен. Более-менее сложная логика превратит вашу БД в legacy code очень быстро.

Нарыл ссылок:
http://en.wikipedia.org/wiki/Stored_procedure
отличная дискуссия: http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx "Stored procedures also will open up a maintenance problem. The reason for this is that they form an API by themselves. Changing an API is not that good, it will break a lot of code in some situations. Adding new functionality or new procedures is the "best" way to extend an existing API"
http://www.devx.com/Java/Article/29337
http://www.praetoriate.com/t_grid_rac_admin_security.htm
http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/1405f97c-29c2-457f-b75a-e4800b085ae6.mspx?mfr=true

Comments

[beskov.livejournal.com]

В смысле умозрительно? SQL знать не надо, этого мало?

Есть проект, где за процедурами стоят расчёты и массовые операции над данными (Фактически, БЛ для DW). Не могу сказать, что это долго проектировалось (гораздо больше проблем с требованиями). Таким образом веб-программист пишет только компоненты интерфейса и веб-сервисы для вызова ХП.

[singalen]

Умозрительно разделение на два уровня абстракции с помощью ХП. Оно будет реальном только если ХП вводят API, отличающийся от CRUD. Потому что CRUD делается через SQL.
Кроме того, этот API должен быть УЖЕ, чем CRUD. Иначе ХП просто подменят собой SQL ПЛЮС добавят какие-то хаки для оптимизации производительности. Думаю, в помянутом проекте так и было, как и в примере cotyary.
В упомянутом проекте веб-программист мог писать, например, только интерфейс и обращение к DAL. DAL при этом может работать на динамическом SQL, например, как Hibernate.

[singalen]

Я имею в виду, для CRUD гораздо лучше пользовать SQL.

[beskov.livejournal.com]

CRUD на ХП я ни разу не далал, так что аргументированно ничего не скажу. Теоретически можно генерить обёртку вокруг таблицы паттерном Active Record, но насколько это может быть полезно - не знаю.

Упомянутый проект был не из сферы OLTP, а из сферы OLAP/DW, так что ORM тут не поможет.

[nponeccop.livejournal.com]

CRUD на ХП я ни разу не далал

А что делают на ХП, если не CRUD и не бизнес-логику?

[beskov.livejournal.com]

А мы именно БЛ и делали. Bulk Loading & Processing.

[singalen]

Насчёт "SQL знать не надо". Давайте посмотрим на выгоды от этого.
1. Простой случай - CRUD. Дать гуишнику набор процедур здесь хуже, чем показать на примере простейший синтаксис select-insert-update-delete, потому что ХП будет гораздо больше. Следовательно, запомнить ХП сложнее. Ну, к API "select-insert-update-delete" добавится API сессии БД, но и это обычно одна-две функции типа "ExecuteQuery".
В то же время, с ХП мы уже получили неслабую проблему - саппортить это API, менять его, менять весь завязанный на него код.
2. Сложный случай - некая бизнес-логика, или update для составного объекта (такого, который сохраняется в несколько таблиц). Чтобы это написать, всё равно нужно привлечь человека, который хорошо знает data access. Что для ХП, что для SQL. Более того, этот код надо потом неприятно саппортить.
Если отсечь случай оптимизации, где без ХП не обойтись, опять ХП проигрывают по supportability.