Должны ли мы отбросить хранимые процедуры и запустить вызовы базы данных из программ Java

Question

Я борюсь за сохранение хранимых процедур в нашей компании. Есть несколько человек, которые говорят, что они плохие, и мы не должны их использовать. Мы используем DB2 на i-серии.

Пожалуйста, помогите в моих аргументах сохранить хранимые процедуры в моей компании.

Answer 1

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

Хранимые процедуры, используемые для предоставления многих преимуществ (безопасность, производительность и т. Д.), Но с параметризованными запросами и лучшей оптимизацией запросов, хранимые процедуры действительно просто добавляют еще один уровень накладных расходов в ваше приложение и дают вам еще одно место, которое вам нужно обновить / изменить. код.

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

Если вы хотите получить более подробную информацию об аргументах отказа от сохраненных настроек, ознакомьтесь со статьей CodingHorror:

Код ужаса: кому все равно нужны хранимые процедуры?

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

Answer 2

Это одна из тех проблем Мармит. если вы в первую очередь программист базы данных, вы будете думать, что хранимые процедуры должны широко использоваться. Если вы программист приложения, скажем, Java или .Net-кодер, скорее всего, вы скажете, что их следует избегать полностью.

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

Есть две большие вещи в пользу хранимых процедур. Во-первых, люди, знающие PL / SQL, вероятно, знакомы с базами данных Oracle (T-SQL и SQL Server и т. Д.) И поэтому будут стремиться писать более качественные программы для этой базы данных (определяемые как программы, использующие преимущества платформы. функции и приспособлены к его функциональности), чем люди, которые этого не делают.

Во-вторых, данные сохраняются. Разработчики приложений любят говорить о «независимости от базы данных», но на самом деле важно независимость от приложения . Внешние интерфейсы приходят и уходят, но модель данных существует вечно. За последние десять лет Java-приложения были написаны как апплеты, сервлеты, JSP, Tiles и Faces, с надстройками в JavaScript, Groovy, AJAX и JSON, которые подключались к базе данных через JDBC, EJB (v1,2, 3) TopLink, Hibernate и IBatis ... прости меня, если я пропустил несколько. Приложения, чей пользовательский интерфейс является надстройкой над слоем хранимых процедур, легче обновить до последних и самых лучших, чем приложения, в которых бизнес-логику необходимо переписывать каждый раз. И они тоже будут работать лучше.

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

Answer 3

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

Обратите внимание, что вы можете писать хранимые процедуры на любом языке IBM i, включая Java, на случай, если это зависит от навыков программирования. Кроме того, у вас есть доступ к ПОЛНОЙ машине, а не только к некоторым внутренним компонентам базы данных. Здесь AS / 400 настолько сильно отличается от любого другого продукта баз данных, что опыт других баз данных просто - по моему мнению - не применим.

Я бы порекомендовал списки рассылки Midrange, так как они имеют наибольшую концентрацию навыков программирования на AS / 400 из всех, что я знаю.

Answer 4

ОК, я выйду в пользу сохраненных процедур.

Во-первых, если вы используете их исключительно, они значительно упрощают рефакторинг базы данных, так как вы можете использовать зависимости, хранящиеся в базе данных, чтобы выяснить, что будет затронуто изменением (в любом случае, в SQL Server не может говорить о других). datbases).

Во-вторых, если вам нужно изменить только запрос, их гораздо проще развернуть.

Их также проще настроить, так как их легко вызывать без запуска приложения.

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

Безопасность также чрезвычайно важна. Если вы не используете процедуры хранилища, вы должны установить права на уровне таблицы или представления. Это открывает базу данных для внутреннего мошенничества. Да, параметризованные запросы снижают риск внедрения sql, но это не единственная угроза, от которой вам нужно защититься. Если у вас есть личные или финансовые данные, и вы не используете хранимые процедуры (и те, у которых НЕТ динамического SQl) и ограничиваете своих пользователей только возможностью делать что-то с помощью процедур, то ваша система находится в чрезвычайной опасности от внутренних сотрудников, которые могут украсть данные или обойти внутренний контроль, чтобы украсть деньги. Прочитайте о внутреннем контроле в стандартах бухгалтерского учета, чтобы понять, почему это проблема.

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

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

Answer 5

Я давний Java-разработчик, который недавно сталкивался с несколькими проектами, в которых интенсивно использовались хранимые процедуры, которые поставили использование хранимых процедур в очень плохое для меня состояние.

Сказав это, я неохотно делаю общее заявление о том, что хранимые процедуры плохи как вариант проектирования системы, потому что на самом деле это зависит от рассматриваемого проекта и того, какие конкретные хранимые процедуры пытаются выполнить.

Я предпочитаю избегать любых хранимых процедур для простых операций CRUD (некоторым может показаться смешным, что хранимые процедуры обрабатывают эти операции, но я сталкивался с несколькими системами, которые это делали) - это заканчиваетсяЭто привело к тому, что для управления этими вызовами процедур из того, что я наблюдал, пришлось написать (и протестировать, и поддерживать) много кода на стороне Java.Лучше всего использовать Hibernate (или некоторую другую библиотеку ORM) для обработки таких операций ... если только по какой-либо другой причине, кроме как для уменьшения объема кода, который необходимо поддерживать.Это также может вызвать проблемы при попытке рефакторинга или внесения каких-либо существенных изменений в систему, поскольку вам нужно не просто заботиться о изменениях класса / таблицы, но и о хранимых процедурах, которые также обрабатывают операции CRUD.И это может усугубиться в дальнейшем, если вы находитесь в ситуации, когда разработчики не могут вносить изменения в базу данных самостоятельно, или существует какой-то формальный процесс для координации изменений между двумя частями системы.

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

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

Answer 6

Они полезны, когда у вас есть многоуровневый набор приложений.Например, одноядерная БД с веб-службами, предлагающими элементарные операции (которые являются хранимыми процедурами) и ESB или набор приложений, потребляющих эти WS.В случае с одним приложением / с одним дБ идея состоит в том, чтобы хранить код в одном месте, как предлагали другие.

Но, ну, это только я.