Я борюсь за использование хранимых процедур в нашей компании. Некоторые люди говорят, что они плохие, и мы не должны их использовать. Мы используем DB2 в i-серии.
Пожалуйста, помогите в моем аргументе, чтобы сохранить хранимые процедуры в моей компании.
ОК, я выйду в пользу сохраненных процедур.
Во-первых, если вы используете их исключительно, они значительно упрощают рефакторинг базы данных, поскольку вы можете использовать зависимости, хранящиеся в базе данных, чтобы узнать, на что повлияет изменение (ну, в любом случае, в SQL Server, не может говорить о других базах данных).
Во-вторых, если вам нужно изменить только запрос, их гораздо проще развернуть.
Их также легче настроить на производительность, поскольку их можно легко вызвать, не запуская приложение.
Если у вас сложная логика, вы сохраните некоторую производительность, поскольку вам не придется отправлять все это по сети на сервер базы данных. Может показаться, что это не так уж важно, но если сложный запрос выполняется тысячи раз в день, он может накапливаться.
Безопасность также чрезвычайно важна. Если вы не используете процедуры магазина, вы должны установить права на уровне таблицы или представления. Это открывает базу данных для внутреннего мошенничества. Да, параметризованные запросы снижают риск внедрения sql, но это не единственная угроза, от которой вам нужно защититься. Если у вас есть личные или финансовые данные, и вы не используете хранимые процедуры (и те, у которых нет динамического SQl) и ограничиваете своих пользователей только возможностью выполнять действия через процессы, то ваша система находится в крайней опасности со стороны внутренних сотрудников, которые могут украсть данные или обход системы внутреннего контроля для кражи денег. Прочтите о внутреннем контроле в стандартах бухгалтерского учета, чтобы понять, почему это проблема.
ORM также имеют тенденцию писать совершенно плохой код SQL, особенно если запрос сложный. Кроме того, когда люди начали использовать их вместо хранимых процедур, я обнаружил, что люди, которые никогда не использовали хранимые процедуры, хуже понимают, как получить данные из базы данных, и часто получают неправильные данные. Использование ORM нормально, если вы уже разбираетесь в SQL и можете определить, когда переписать автоматически сгенерированный код во что-то, что работает лучше. Но у слишком многих пользователей нет навыков для написания сложного кода, потому что они никогда не изучали основ.
Наконец, поскольку вы уже сохранили процессы для своего приложения, полное избавление от них - это способ внести новые ошибки, поскольку вам пришлось сгенерировать новый код.
Вам это не понравится, и я, вероятно, предаюсь забвению, но я с остальной частью вашей компании.
Хранимые процедуры, используемые для предоставления многих преимуществ (безопасность, производительность и т. Д.), Но с параметризованными запросами и лучшей оптимизацией запросов, хранимые процедуры на самом деле просто добавляют еще один уровень накладных расходов к вашему приложению и дают вам другое место, где вам нужно обновить / изменить код.
Я предпочитаю хранить все в одном месте, чтобы, когда мне нужно отредактировать код, я мог перейти в одно место и внести там свои изменения.
Если вы хотите получить более подробную информацию об аргументах в пользу отказа от хранимых инструкций, ознакомьтесь с этой статьей CodingHorror:
Ужас программирования: кому все равно нужны хранимые процедуры?
... и я только что заметил, что это статья 2004 года. Я должен верить, что с тех пор базы данных стали лучше, а это значит, что сегодня это будет звучать даже более верно, чем тогда.
Выполнение всего через JDBC по сути означает, что вы вставляете сетевой уровень между вами и базой данных. В целом это означает, что данные более «удаленные» и медленнее приходят к вам. Хранимые процедуры могут работать непосредственно с данными внутри базы данных, и результирующая разница в скорости может вас удивить.
Обратите внимание, что вы можете писать хранимые процедуры на любом языке IBM i, включая Java, если это зависит от навыков программирования. Кроме того, у вас есть доступ к ПОЛНОЙ машине, а не только к некоторым внутренним компонентам базы данных. Здесь AS / 400 настолько сильно отличается от любого другого продукта баз данных, что опыт других баз данных просто - по моему мнению - неприменим.
Я бы порекомендовал списки рассылки Midrange, так как они обладают наибольшей концентрацией навыков программирования AS / 400, о которых я знаю.
Это одна из проблем Marmite. Если вы в первую очередь программист баз данных, вы подумаете, что хранимые процедуры следует использовать широко. Если вы программист приложений - скажем, программист на Java или .Net - скорее всего, вы скажете, что их следует полностью избегать.
Это не означает, что прикладные программисты хотят писать свои собственные операторы SQL. Нет, в наши дни они, как правило, хотят абстрагироваться от всего, что скрывается за запутанными услугами ORM. Их не легче понять, чем хранимые процедуры, но они доступны в одной среде IDE, поэтому для них требуется меньше переключения контекста.
Есть два важных момента в пользу хранимых процедур. Во-первых, люди, которые знают PL / SQL, вероятно, знакомы с базами данных Oracle (T-SQL, SQL Server и т. Д.), И поэтому будут стремиться писать лучшие программы для этой базы данных (определяемые как программы, которые используют преимущества платформы функции и соответствуют его функциональности), чем люди, которые этого не делают.
Во-вторых, данные сохраняются. Разработчики приложений любят говорить о «независимости базы данных», но что действительно важно, так это независимость приложения. Внешние интерфейсы приходят и уходят, но модель данных существует вечно. За последние десять лет Java-приложения были написаны в виде апплетов, сервлетов, JSP, плиток и граней с надстройками на JavaScript, Groovy, AJAX и JSON, подключающимися к базе данных через вручную свернутый JDBC, EJB (v1,2, 3), TopLink, Hibernate и IBatis ... простите, если я пропустил несколько. Приложения, пользовательский интерфейс которых представляет собой оболочку над слоем хранимых процедур, легче обновить до последней и лучшей версии, чем приложения, в которых бизнес-логику приходится каждый раз переписывать. И они тоже будут работать лучше.
Однако в долгосрочной перспективе приложения, которые напрямую взаимодействуют с базой данных, вероятно, исчезнут. Все будет общаться со служебной шиной, и она решит, откуда брать данные. Конечно, магазинам, где база данных предоставляется через хорошо продуманный API хранимых процедур, может оказаться легче перейти в этот дивный новый мир, чем тем местам, которым придется извлекать все из своей логики ORM.
Они полезны, когда у вас многоуровневый набор приложений. Например, одноядерная БД с веб-службами, предлагающими атомарные операции (которые оказываются хранимыми процедурами), и ESB или набор приложений, использующих эти WS. В случае с одним приложением / одним БД идея состоит в том, чтобы хранить код в одном месте, как предлагали другие.
Но что ж, это только я.
Я давний разработчик Java, который недавно столкнулся с несколькими проектами, в которых интенсивно использовались хранимые процедуры, что поставило использование хранимых процедур в очень плохой для меня свете.
Сказав это, я не хочу делать общее заявление о том, что хранимые процедуры плохи как вариант проектирования системы, потому что на самом деле это зависит от рассматриваемого проекта и того, что конкретные хранимые процедуры пытаются выполнить.
Я предпочитаю избегать каких-либо хранимых процедур для простых операций CRUD (для некоторых это может показаться смешным, если хранимые процедуры обрабатывают эти операции, но я встречал несколько систем, которые делали это). кода, который должен быть написан (и протестирован и поддержан) на стороне Java для управления этими вызовами процедур, из того, что я наблюдал. Лучше просто использовать Hibernate (или какую-либо другую библиотеку ORM) для обработки таких операций ... если только по той причине, что это имеет тенденцию уменьшать объем кода, который необходимо поддерживать. Это также может вызвать проблемы при попытке рефакторинга или внесения каких-либо существенных изменений в систему, поскольку вам нужно не только заботиться об изменениях классов / таблиц, но и хранить хранимые процедуры, которые также обрабатывают операции CRUD. И это может усугубиться еще больше, если вы находитесь в ситуации, когда разработчики не могут вносить изменения в базу данных сами, или существует какой-то формальный процесс для координации изменений между двумя частями системы.
С другой стороны, наличие хранимых процедур, требующих ограниченного взаимодействия с кодом Java (в основном, вы просто запускаете вызов одного с несколькими аргументами) и выполняются в полуавтономном режиме, тоже не страшно. Я столкнулся с несколькими ситуациями (особенно когда мы переносили или импортируем данные в систему), когда использование хранимой процедуры было гораздо лучшим способом, чем написание кучи кода Java для обработки функциональности.
Я предполагаю, что реальный ответ здесь будет заключаться в том, что вам следует изучить, что каждая процедура хранилища в системе делает в настоящее время, и оценивать их в каждом конкретном случае, чтобы определить, возможно ли легче обрабатывать операцию на Java или в базе данных. Некоторые могут работать лучше на Java (либо с помощью библиотеки ORM, либо с помощью реального рукописного кода), некоторые - нет. В любом случае цель всегда должна заключаться в том, чтобы система была понятна и проста в обслуживании для всех, а не только для того, хороши или плохи хранимые процедуры сами по себе.
