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

[cotyary.livejournal.com]

1. Ну если так смотреть, то любая программа это процесс оптимизации ввода пользователя для достижения требуемого результата Ж;о). А если серьёзно, то (взято просто для примера) в физически 4х-уровневом приложении (веб-клиент, веб-сервер, апп-сервер, сервер БД) нагрузка каждого из компонентов бизнес-логикой осуществляется именно из соображений производительности. В частности (но не только), сетевой производительности - времени синхронного ожидания ответа от следующего компонента. И логика в базе будет всегда - глупо делать джойны на стороне апп-сервера. Вопрос, в общем, в объёме этой логики и, как ты совершенно правильно заметил, в "защищённости" структуры данных (и самих данных) от этой логики.
Кстати, боттлнек не обязательно находить, его можно предусмотреть Ж;-) В описанном проекте, просто было очевидно, что он будет.

2. Строго говоря - нет. Кроме того, SQLJ - это таки язык хранимых процедур.

ЗЫ. Я не спорю (ибо с основной идеей совершенно согласан), я дополняю.

Планирование узких мест

[nponeccop.livejournal.com]

Кстати, боттлнек не обязательно находить, его можно предусмотреть Ж;-) В описанном проекте, просто было очевидно, что он будет.

ИМХО стратегия поэтапной разработки как раз и подразумевает под собой запланированные боттлнеки - как архитектурные боттлнеки, так и классические боттлнеки производительности.

В этой связи ужасно, если после первой версии продукт переходит к другой команде и понятно что новая команда предпочтет код выкрасить и выбросить и написать заново свой.

Re: Планирование узких мест

[cotyary.livejournal.com]

Предусмотреть, это, вообще говоря, не запланировать Ж;-)
Предусмотреть - это значит знать что он будет, и в изначальном дизайне сделать так, чтоб он легко обходился.
Запланировать - это, проще говоря, вставить его туда Ж;о)

С остальным - целеком и полностью согласен. Из буржуйского: люблю смотреть, на код, который делали контракторы - часто "не моё - не жалко" (или "после нас хоть потоп") есть основной принцип разработки

Re: Планирование узких мест

[nponeccop.livejournal.com]

Из буржуйского: люблю смотреть, на код, который делали контракторы - часто "не моё - не жалко" (или "после нас хоть потоп") есть основной принцип разработки

Я как раз хотел поспорить с таким взглядом на вещи. Ну не было у них возможности в первой версии сделать оптимизацию архитектуры. Особенно это касается дизайнов со слабой связанностью на верхнем уровне и множеством мелких компонент - компонент может быть написан как угодно плохо внутри, пишется, отлаживается и дальше просто не трогается и не рефакторится чтобы не поломать. И никому снаружи не мешает.

Код который таки мешает - естественно при первой необходимости рефакторится в более цивилизованный. Я вот недавно написал полнейшую лапшу в 1к строк сишного кода и отдал ее в таком виде заказчику в надежде что она работает. Код по сути R&D-шный прототип, Proof of Concept, но я навесил на него cgi-интерфейс и отдал его для установки в production-систему.

Является ли это свидетельством моей нечистоплотности как разработчика?

Могу ли я написать код более красиво не зная для чего эта красота будет нужна, то есть для упрощения внесения какого рода изменений его оптимизировать? То есть я хочу сказать что "красивый" код сделанный из рабочего некрасивого как раз и будет преждевременной оптимизацией.

Re: Планирование узких мест

[cotyary.livejournal.com]

Ну не было у них возможности в первой версии сделать оптимизацию архитектуры - "Никогда нет времени сделать один раз нормально, но всегда находится время потом переделать" (с)
Могло и не быть - бюджет (времени-ли, денег) не резиновый. Но подобные вещи порождают сложности в отладке, тестировании и последующем понимании. А так-же влекут к лавинообразному наростанию грязи в проекте (особенно если его делают много людей). Как результат, эту версию новой команде (как вы правильно заметили) приходится переписывать заново, отчаявшись что-то там понять. Намедни откорректил процедурку в полтора экрана, в которой было 3 цикла, причём 3й был вложен во второй. В результате код ужался в трое (а если не считать окружающий трай-кетч, то и четверо) и значительно упростилось условие. И это еще не самый жуткий пример.

Особенно это касается дизайнов со слабой связанностью - во-во, преполагается, что дизайн довольно хорошо продуман. Если это так, то баги в компонентах - действительно мелочи.

И никому снаружи не мешает - если он отдаёт правильный результат

Является ли это свидетельством моей нечистоплотности как разработчика? - вообще говоря - да. Что Вас к этому подвигло - это уже другой вопрос Ж;о) Может приславутая экономическая нецелессообразность. Ж;о)

То есть я хочу сказать что "красивый" код сделанный из рабочего некрасивого как раз и будет преждевременной оптимизацией. - и да и нет.
Да - ибо бессмысленная оптимизация - просто потраченное ни на что время
Нет - это так только если она действительно бессмысленна и никто другой Ваш код не будет править и/или отлаживать. + Ваш код стоек достаточно, чтоб выдержать все разумно-возможные изменения "окружающей среды" с приемлемым качеством результата/ производительностью/ ресурсоёмкостью

ЗЫ. Адептом РУПа или ХР не являюсь. Абсолютно не верю ни в один. Считаю, что всё хорошо в меру.
ЗЗЫ. Мы, в общем, глубоко в оффтопе.

Вставка узких мест

[nponeccop.livejournal.com]

Моя практика приводит именно к вставке боттлнека. Скажем, к написанию приложения, критичного к эффективности IO, сначала на синхронном API, потому что так проше и синхронный прототип будет готов быстрее. Но уже заранее зная, что потом ("когда-нибудь", "во второй версии", добавьте свой вариант) этот код придется просто выбросить и написать асинхронный. Причем выбросить не только низкоуровневый слой, инкапсулирующий апи, но и логический код.

Ведь выбор в сторону неэффективного кода делается именно из-за того что неявное хранение состояния в последовательности операторов гораздо проще и быстрее, чем реализация event driven state machine. И писать "логический код" так, чтобы он работал и в синхронном и "в случае чего" - в асинхронном режиме, смысла никакого нет опять таки из-за ожидаемой краткосрочной "экономии".

Re: Вставка узких мест

[cotyary.livejournal.com]

Причем выбросить не только низкоуровневый слой, инкапсулирующий апи, но и логический код. - может да, может нет. Асинхронность часто можно абстагировать от логики. Иногда это надо делать, иногда - нет (та-же загрузка изначальных конфигов) - зависит от задачи.
И писать "логический код" так, чтобы он работал и в синхронном и "в случае чего" - в асинхронном режиме, смысла никакого нет опять таки из-за ожидаемой краткосрочной "экономии". - тут важно не пропустить тот момент когда код на синхронику завязан настолько, что для асинхронности нужно переписать вообще весб проект. Ну при условии, что эта асинхронность вообще хоть как-то там нужна.

С идеей прототипирования согласен абсолютно. И в том, что 80% прототипа выбросится, так это скорее всего.

Кстати асинхронное выполнение это отнють не единственный способ бороться с ботлнеками. Если база или сеть, например, загружена на 95% оно Вам мало поможет.

[singalen]

1. От только не надо абсурдных обобщений.

Кстати, боттлнек не обязательно находить, его можно предусмотреть
http://en.wikipedia.org/wiki/Optimization_(computer_science): Tony Hoare first said, and Donald Knuth famously repeated, "Premature optimization is the root of all evil."

С остальным согласен.

[cotyary.livejournal.com]

Да сдалась тебе эта оптимизация Ж;-))))
Ну скажи, предварительная (или черновая) валидация вводимых данных в тонком клиенте - это оптимизация?
Нет, это нормальная логика тонкого клиента.
Так почему тогда корректная выборка и компоновка данных, которые должны происходить в реляционных терминах, сделанные на сервере БД - это оптимизация?
Я не говорю, что надо всю логику в базу засунуть. Но, иногда, часть поместить туда всё-же стоит. Или предусмотреть, что какой-то компонент может туда перекочевать. И бить архитектуру программы на уровни так, чтоб эти уровни могли малой кровью быть перенесены на другой сервер (в смысле, логически ближе-дальше от клиенской машины) или продублированы там это необходимость при проектировании больших систем. А что будет причиной этого преноса оптимизация-ли (и оптимизация по чему) или положение звёзд - это, в общем, дело десятое.

[nponeccop.livejournal.com]

Вы же сами говорите, что мы же не знаем, что именно будет причиной переноса. Соответственно наш "гибкий" код всё равно окажется недостаточно гибким.

Мне кажется, что разумно писать плохой код с максимально быстрой скоростью, а если он перестает работать - то прохачить его пару раз. А если и после этого он не работает - выкинуть и написать по-человечески с учетом статистики по местам прохачивания. Конечно, если специфика системы такова, что в среднем никакой код не удается заставить работать путем умеренного грязного прохачивания лапши, то надо сразу писать хороший код (но опять же с учетом специфики мест где предполагается внесение хаков в случае лапшевидного варианта).

Вы считаете, что случаев, когда можно написать (создать рабочую систему) и как попало - крайне малое количество? Начиная с какого примерно объема системы в человекогодах разработчикам нужно отрубать очередной палец за каждую попытку писать лапшу?

[cotyary.livejournal.com]

Вы же сами говорите, что мы же не знаем, что именно будет причиной переноса. Соответственно наш "гибкий" код всё равно окажется недостаточно гибким. - сие не факт. Ключевое слово - малой кровью

По поводу второго абзаца. Представьте, что Вы не сможете делать суппорт в этой системе после выхода её в лайф. Вообще не сможете. В лучшем случае дадут логи посмотреть недельной давности.

Вы считаете, что случаев, когда можно написать (создать рабочую систему) и как попало - крайне малое количество? - нет, я так не считаю. Это просто очень дорого в последующей поддержке. Что может быть плюсом, если оплата программисту почасовая.

[singalen]

Самый гибкий код - тот, который самый простой.

[cotyary.livejournal.com]

Витя, ты, как всегда, по существу и в точку.
Респект