Stored procedures security
27/11/06 22:55![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalen![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif){kind=small}
ru_sql пока меня не пускает, ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
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
Tags:
(no subject)
3/1/07 09:02 (UTC)Мне, собственно, было интересно, действительно ли этот подход более секьюрен, как кажется на первый взгляд. А аудит достуап можно сделать и по SQL-запросам.
Второй. Не могли бы Вы поподробнее описать системы, в которых были проблемы с производительностью из-за "места для хранения объектов", и сами проблемы?
А если у вас есть сравнительные оценки трудозатрат на системы с бизнес-логикой в БД, в domain model и с размазанной по GUI, то это будет вообще волшебно. Хотя бы навскидку.
написание БЛ на pl-sql довольно удобное занятие (кстати отладчики с среды разработки не хуже чем для java)
О, а как у PL-SQL с юнит тестами? С рефакторингами, есть extract method? С инкапсуляцией на уровне объектов (про пакеты знаю)? С записью в лог из транзакции (в последний раз я смотрел API для 8i, было плохо)? С метриками кода? С инструментами автоматического анализа кода, вроде FindBugs?
Да, если внедренцы могут быстрее исправить баг, это уменьшит его стоимость в десяток раз, так что это удобно. И даже если при этом исправить этот баг в 5 раз дороже, чем в коде domain model, мы выигрываем в сопровождении - но проигрываем в разработке.
За внедренцев я, конечно, рад, но разработка меня интересует больше.
Примерно такой же выигрыш даст скриптование domain layer-а или DSL, и саппортить их будет ещё дешевле. Но это ещё более сложно, чем создать domain model, проще свалить всё в ХП.
(no subject)
3/1/07 12:31 (UTC)Подробнее по поводу "места для хранения объектов" написанно у Кайта (хотя он конечно лицо заинтересованное :) на я с его доводами по большей части согласен). Из того что приходилось видеть самому проблеммы начинаються как только на клиенте (сервер приложений) пытаються что либо проджойнить а это случаеться сплошь и рядом либо возникает какая-либо операция с множеством объектов, либо выборка объектов по сложному критерию если объект сложно составной. Еще что интересно такой подход часто влечет за собой переписывание функционала имеющегося в базе (блокировки, транакционый механизм, кэши, ограничение целостности) вы сами в данном обсуждении высказывали мысль самим писать кэш запросов :).
По поводу трудозатрат тут на мой взгляд все зависит от объема того что требуеться написать а так же от необходимости сопровождения (расширения функциональности) написанного понятно что при большом объеме кода или при необходимости сопровождения код размазаный по UI не катит совершенно как говориться легче переписать чем дороботать, что же касаеться domain model (если я под этим понимаю то же что и вы) и БЛ в БД то я не вижу особых противоречий по написанию системы с использованием этих двух подходов совместно все видемо зависит от конкретной системы (требований к ней).
По поводу удобства средств для PL-SQL. С unit тестами на PL-SQL все нормально :). Есть правда проблеммы (решаемые но не так легко и красиво как хотелось бы) с тестированием клиент-серверных программ вообще..., но они к наличию либо отсутствию кода в БД не относяться. Рефакторинг во всяком случае extract method есть. По поводу записи в лог из транзакции то же все хорошо причем в 8i необходимые средства уже были.(dbms_application_info, dbms_aq, dbms_pipe или dbms_alert что из этих средств не требует фиксации транзации не вскидку не помню, использование автономных транзакции, использование вызова внешних процедур). Как видите средств много нужно только выбрать более удобное... Насчет метрики кода и анализа честно говоря не знаю как то оно не нужно было принципиальных причин для отсутствия таких инструментов не видно так что наверное если поискать то что-то найдеться. Насчет скрытия методов на уровне объектов в том же глубоко всеми любимом лиспе живут же как то люди со скрытием методов на уровне пакетов и ничего не жалуются... А если серьезно то ИМХО не смотря на наличие объектов PL-SQL для истино объектно-ореентированного програмирования не слишком подходит, но опять же это видь только одна из многих парадигм программирования и на ней свет клином не сошелся... можно хорошо писать большие системы и без объектов так же как можно ужасно спроектировать систему с объектами.
Безопасность, "свалка для хранения данных"
3/1/07 13:21 (UTC)Джойн на клиенте и сложные выборки на нём же - это, ПММ, признак плохого/неудобного DAL или неумения им пользоваться. Все три случаются часто, да :) Так что плюс один.
Если не сравнивать плохой клиент с хорошим BL на уровне СУБД, а только "плохой с плохим" то получим такой выбор:
За логику на клиенте (он же аппсервер):
- инкапсуляция на уровне классов;
- более простой deployment на разработчика клиента, если БД одна на всех;
- больше программистов на рынке;
- больше инструментов на рынке;
Против:
- джойны на клиенте;
- сложные выборки;
За логику на сервере БД (рассмотрим Oracle):
- простота доступа к данным;
- производительность;
- дешевле в сопровождении; (как с контролем клиентских версий?..)
Против:
- худшая структурированность кода (инкапсуляция на уровне пакетов);
- то, что я не знаю тамошних инструментов и не могу их оценить :)
...to be continued
Анализ кода, ОО парадигма
3/1/07 13:37 (UTC)Я понимаю, можно писать без ОО парадигмы, чисто процедурно, и получать при этом хорошие результаты. Но это сложнее. ОО хороша тем, что даёт более высокоуровневый подход и, соотв, код становится проще.
Например, на C обычно всё равно приходят либо к групировке функций по объектам, либо к коду в виде спагетти.
(no subject)
21/3/07 08:53 (UTC)http://www.apollo-pro.com/help/pl_unit.htm
С записью в лог из транзакции (в последний раз я смотрел API для 8i, было плохо)
http://log4plsql.sourceforge.net/ Не уверен, что там используются автономные транзакции, но в 9-ке они появились именно для таких задач.
С рефакторингами, есть extract method? С инкапсуляцией на уровне объектов (про пакеты знаю)?
Я щас копаю в эту сторону, обчитавшись Фаулера - PL/SQL немного жмёт. Нет полиморфизма, сокрытие только через методы. Пакеты можно считать singleton, но на одних их много не построишь.