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:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Компонентная архитектура
28/11/06 10:32 (UTC)"...Изолированные друг от друга слои системы реализуют таким образом инкапсуляцию и позволяют вносить изменения в каждый уровень (например, с целью рефакторинга) с минимальным воздействием на прочие. Кроме того, такой "многослойный пирог" позволяет распределять задачи каждого уровня по разным физическим узлам, оптимизируя характеристики оборудования под решаемые задачи и вводя при необходимости распределение нагрузки, динамически перенаправляя поток вызовов на дублирующие узлы одного уровня (фермы, репликация).
Компонентная архитектура также позволяет добиться более эффективной совместной разработки, когда каждый разработчик или группа отвечает за определённый слой, являясь как бы центром компетенции по технологиям данного слоя, что особенно важно при создании больших и/или высокопроизводительных систем. Например, разработчик веб-сервисов и бизнес-логики может быть экспертом в технологиях java или c#, но ему не обязательно быть знатоком баз данных и SQL - все необходимые методы доступа к данным и структуры для их хранения создаст разработчик БД (сокрытие сложности БД).
В такой архитектуре хранимые процедуры могут эффективно реализовывать уровни доступа к данным (прежде всего) и, возможно, бизнес-логики."
(no subject)
28/11/06 16:52 (UTC)(no subject)
28/11/06 17:16 (UTC)CALL оставляет возможность разработчику БД менять структуры хранения данных (рефакторить), не затрагивая внешнего программиста.
(no subject)
28/11/06 17:49 (UTC)(no subject)
29/11/06 07:46 (UTC)Есть проект, где за процедурами стоят расчёты и массовые операции над данными (Фактически, БЛ для DW). Не могу сказать, что это долго проектировалось (гораздо больше проблем с требованиями). Таким образом веб-программист пишет только компоненты интерфейса и веб-сервисы для вызова ХП.
(no subject)
29/11/06 08:45 (UTC)Кроме того, этот API должен быть УЖЕ, чем CRUD. Иначе ХП просто подменят собой SQL ПЛЮС добавят какие-то хаки для оптимизации производительности. Думаю, в помянутом проекте так и было, как и в примере
В упомянутом проекте веб-программист мог писать, например, только интерфейс и обращение к DAL. DAL при этом может работать на динамическом SQL, например, как Hibernate.
(no subject)
29/11/06 08:51 (UTC)(no subject)
29/11/06 09:27 (UTC)Упомянутый проект был не из сферы OLTP, а из сферы OLAP/DW, так что ORM тут не поможет.
(no subject)
29/11/06 22:40 (UTC)А что делают на ХП, если не CRUD и не бизнес-логику?
(no subject)
30/11/06 08:28 (UTC)(no subject)
29/11/06 09:05 (UTC)1. Простой случай - CRUD. Дать гуишнику набор процедур здесь хуже, чем показать на примере простейший синтаксис select-insert-update-delete, потому что ХП будет гораздо больше. Следовательно, запомнить ХП сложнее. Ну, к API "select-insert-update-delete" добавится API сессии БД, но и это обычно одна-две функции типа "ExecuteQuery".
В то же время, с ХП мы уже получили неслабую проблему - саппортить это API, менять его, менять весь завязанный на него код.
2. Сложный случай - некая бизнес-логика, или update для составного объекта (такого, который сохраняется в несколько таблиц). Чтобы это написать, всё равно нужно привлечь человека, который хорошо знает data access. Что для ХП, что для SQL. Более того, этот код надо потом неприятно саппортить.
Если отсечь случай оптимизации, где без ХП не обойтись, опять ХП проигрывают по supportability.
Неопытные разработчики и размер проекта
28/11/06 21:25 (UTC)Это не "не очень опытные", а "совсем нулевые" веб-разработчики, в 2006-то году. Я вижу такую эволюцию веб-программиста (и веб-проектов, которые он может потянуть):
1) Нулевой веб-программист. Смешивается SQL, PHP и HTML.
Если мало слоя логики (я называю такие проекты "базками"), то этот подход начинает давать сбои уже при 10 таблицах. Если логики много - то даже раньше.
2) Не очень опытный веб-программист. HTML выносится в презентационный слой (шаблоны, ASP.NET controls и иже с ними), но SQL мешается с PHP. Максимум - создаются абстракции таблицы и формы редактирования записи для простых случаев.
Такой подход работает в случае проекта размером 50 таблиц прекрасно, даже при наличии логики обитающей целиком в PHP или во внешних компонентах (в моем случае было что-то типа RPC на Perl поверх SSH).
Ваш подход необходим на гораздо более высоких уровнях сложности проектов и компетенции разработчиков - когда второй подход перестанет хорошо масштабироваться. Например, в случае колоссальной бизнес-логики, когда мало страниц просто отображают и редактируют профильтрованные записи в таблице. Или в случае 400 таблиц, когда в данных чёрт ногу сломит и бывают случаи, когда изменения в БД не затрагивают логики страниц. В малых проектах (скажем, 3 человекогода) такие случаи крайне редки и слой абстракции не приводит к изоляции изменений.
Re: Неопытные разработчики и размер проекта
29/11/06 07:49 (UTC)Имхо, чем раньше они прочитают про повторное использование, уровни абстракции, связность и т.д., составляющие плоть и кровь компонентного подхода и поймут, зачем и для чего это нужно - тем лучше и для их карьеры, и для их работодателей, и для клиентов.
Re: Неопытные разработчики и размер проекта
29/11/06 12:05 (UTC)Re: Неопытные разработчики и размер проекта
29/11/06 08:30 (UTC)Да и второй, в общем, тоже...
Re: Неопытные разработчики и размер проекта
29/11/06 12:04 (UTC)Определение Фаулера для паттерна Transaction Script (http://www.martinfowler.com/eaaCatalog/transactionScript.html) выглядит довольно убого. Оно касается только того как организован слой данных в подобных системах? Или все приложения-"базки" целиком (включая код, перекачивающий данные как есть из слоя данных в слой представления) вы хотите представить в виде набора сценариев транзакций?
(no subject)
29/11/06 12:26 (UTC)Транзакциями там названы бизнес-транзакции, то есть операции пользователя. И таки-да, каждая операция пользователя - от клика кнопки до записи в базу - записана в коде, в каком-нибудь OnClick.
Не относитесь свысока к классикам, это может звучать как "Тётькин правит Пастернака".
(no subject)
29/11/06 12:38 (UTC)