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]

При поддержке в СУБД схемы метаданных (Information_Schema в стандарте SQL99?) и динамического SQL с помощью ХП могут очень эффективно решаться задачи кодогенерации, например:

а) Создание таблиц-дубликатов для ведения истории изменений для задачи аудита изменений в БД и соответствующих триггеров (см.выше).

б) Приведение имён объектов (унаследованной) БД к стандарту, например создание явных семантически значимых имён внешних ограничений, ограничений типа NOT NULL, первичных ключей, индексов и т.д. См. пример для NOT NULL и Oracle.

Если что-то тут неправильно, готовы выслушать.

Re: Кодогенерация

[singalen]

а) Испугался задачи и молчу. Не понял, но кажется, что это что-то страшное :)
б) Это тот же select+DDL, ХП здесь - только форма. К тому же, на DDL это было бы более прозрачно и отлаживаемо.

Re: Кодогенерация

[beskov.livejournal.com]

б) не понял, что значит SELECT + DDL? Причём тут DDL? Есть готовая база, именование ограничений которой задавалось системно - через генерацию самой СУБД. Теперь нужно привести всё это в читаемый вид.

[singalen]

У меня то же выглядело бы примерно так:
sqlplus -f "SELECT constraint_name name, table_name tab, search_condition cond
FROM user_constraints
WHERE constraint_type = 'C'
AND constraint_name LIKE 'SYS%'" > constraints.txt
perl gen_con_names.pl < constraints.txt > rename_constraints.sql
далее выполнить rename_constraints.sql.
При этом rename_constraints.sql можно предварительно просмотреть, подправить, отладить на тексте, а не на реальной базе.

[beskov.livejournal.com]

Угу, для задач администрирования скорее важны скрипты, которые могут теоретически быть написаны в виде анонимных блоков на *-SQL языке, или даже сохранены в БД, превратившись таким образом в ХП. Но в таком случае применение ХП не даёт особых преимуществ в смысле их прекомпилированности, т.к. административные задачи разовые, и для них скорость выполнения запросов не так критична.

Спасибо, учту.