Есть ли альтернатива хранимым процедурам?
Есть ли альтернатива хранимым процедурам, безопасным и быстрым, а также хранимым процедурам. я знаю только Hibernate. Есть ли другие подобные технологии?
Рич Б: Я бы хотел, чтобы вы опубликовали это как ответ, чтобы я мог проголосовать за него :)
@Milan: Спасибо за согласие, но он в нужном месте. ;)
извините, где я не понял sprocs? Написание кода sproc занимает много времени, и я подумал, есть ли альтернатива?
См. stackoverflow.com/questions/167154/… для обсуждения, похожего на это.
Также см. stackoverflow.com/questions/119540/… для еще одного обсуждения хранимых процедур.
@Serik: Вы переносите NHibernate с помощью sprocs, и я не думаю, что вы действительно понимаете, что такое sprocs. Было бы полезно, если бы вы задали более широкий вопрос, предлагая вместо этого небольшое обучение по sprocs.
Я думаю, что задал вопрос неправильно, и теперь у меня другие ответы, которых я ожидал
Ответы 8
Вы можете выполнять динамический SQL настолько безопасно и быстро, насколько это возможно для хранимых процедур, это просто требует некоторой работы. Конечно, чтобы сделать хранимые процедуры безопасными и быстрыми, нужно потрудиться.
Угадайте, есть какие-то хранящиеся там фанаты-проки.
Без шуток. Лэнс, я думаю, ваш ответ может во многом зависеть от движка БД, о котором вы говорите.
Да, я согласен. Я старался не включать в ответ какие-либо подробности, чтобы не начать какую-то войну.
Динамический sql не так безопасен, как правильно написанная хранимая процедура. Вы можете ограничить прямой доступ к таблицам с помощью хранимых процедур (если они, в свою очередь, не используют динамический sql), что поможет вам защитить вашу базу данных от внутренних пользователей. (Те, кто чаще всего ворует данные или совершает мошенничество.)
@HLGEM: Мне нужно было бы увидеть пример, чтобы в это поверить. В конце концов, я могу предоставлять отдельные права выбора, вставки, обновления и удаления отдельным пользователям. Не уверен, насколько безопаснее может быть.
@ S.Lott: ваша хранимая процедура может реализовать правило, которое означает, что конкретный пользователь может обновлять только подмножество строк или может удалять только те строки, которые находятся в состоянии «EXPIRED» или что-то еще. Вот почему они строже для безопасности, чем разрешение DELETE для таблицы.
Hibernate - это объектно-реляционная постоянная служба.
Хранимая процедура - это подпрограмма внутри системы реляционной базы данных.
Не то же самое.
Если вам нужна альтернатива Hibernate, вы можете проверить iBatis на весну
да. вы можете использовать динамический sql, но мне лично больше нравятся хранимые процедуры.
1) Если вы используете MS SQL Server, он сгенерирует план запроса, который должен позволить хранимой процедуре выполняться быстрее, чем простой динамический sql.
2) Может быть проще и эффективнее исправить ошибку в хранимой процедуре, особенно если ваше приложение вызывает эту процедуру в нескольких местах.
3) Мне нравится инкапсулировать логику базы данных в базе данных, а не во встроенном sql или файле конфигурации приложения.
4) Создание хранимой процедуры в базе данных позволит sql-серверу выполнять некоторые синтаксические и проверочные проверки во время разработки.
Динамический SQL также может получать планы запросов, это миф (верный когда-то в прошлом), что только сохраненные процессы получают планы запросов.
Динамический SQL получает план запроса, но если ваш динамический sql вообще изменится из-за значений параметров, план запроса придется перестроить, что снизит производительность.
Да, вы правы, точно так же, как использование значений параметров может повлиять на сохраненные процессы. Мне также понравились хранимые процессы, но для моих обычных нужд я просто хотел бы, чтобы они были более динамичными!
В базах данных нет логики - в приложениях есть. Кодирование без SQL или использование нейтрального подхода к БД, такого как NHibernate Criteria или HQL, и сохранение этой логики в классах DAO имеет смысл с точки зрения кодировщиков OO. Это и наблюдения Лэнса оправдали бы голосование "против".
С точки зрения специалиста по базам данных, включение в приложение важной бизнес-логики вообще не имеет смысла. Доступ к базам данных обычно осуществляется из нескольких источников. Основные правила должны быть на уровне базы данных, иначе у вас могут возникнуть проблемы с целостностью данных.
Хранимые процедуры - это место для размещения кода (SQL), который выполняется в базе данных, поэтому я понимаю, что вопрос означает
"есть ли другой способ упаковать код, работающий в базе данных?"
Есть несколько ответов:
- Нет ничего, что было бы довольно таким же, как хранимая процедура, но есть альтернативы, которые вы могли бы рассмотреть.
- Вы можете написать весь свой SQL в виде строк внутри своего клиентского кода (Java или что-то еще)
- Однако при этом возникают различные проблемы (потеря герметичности, плотная связь -> более сложное обслуживание), и это не очень хорошая идея.
- Вы можете использовать ORM, например NHibernate, который вставляет слой между вашей клиентской логикой и базой данных. ORM генерирует SQL для выполнения в базе данных. В ORM сложнее выразить сложную бизнес-логику, чем в хранимой процедуре (широкое обобщение!).
- Своего рода промежуточный вариант - определить ваш собственный уровень доступа к данным (DAL) в java (или в любом другом, что вы используете) и сохранить его отдельно от основной части клиентского кода (отдельные классы / пространства имен / и т. д.), Чтобы ваш клиент выполняет вызовы DAL, а DAL интерпретирует их и отправляет SQL в базу данных, возвращая результаты из базы данных обратно клиенту.
Хм, мне кажется, очевидная альтернатива хранимым процедурам - это написание кода приложения. Вместо того, чтобы, скажем, писать процедуру магазина для разноски дебета каждый раз, когда разносится кредит, вы можете написать код приложения, который записывает оба.
Возможно, я здесь слишком упрощаюсь или упускаю суть вопроса.
A stored procedure is a subroutine available to applications accessing a relational database system. Stored procedures (sometimes called a proc, sproc, StoPro, or SP) are actually stored in the database data dictionary.
Typical uses for stored procedures include data validation (integrated into the database) or access control mechanisms. Furthermore, stored procedures are used to consolidate and centralize logic that was originally implemented in applications. Large or complex processing that might require the execution of several SQL statements is moved into stored procedures, and all applications call the procedures only.
Stored procedures are similar to user-defined functions (UDFs). The major difference is that UDFs can be used like any other expression within SQL statements, whereas stored procedures must be invoked using the CALL statement
..от Википедия
Думаю, вам нужно прочитать эту статью и переосмыслить свой вопрос. Hibernate не имеет ничего общего с сохраненными процессами.
Было бы лучше, если бы вы сказали, почему ищете альтернативы, а что насчет хранимых проков тебе не нравится?
Некоторые базы данных (например, PostgreSQL) также позволяют писать хранимые процедуры в разные языки. Так что, если вы действительно хотите, вы можете написать их на Python или Java или тому подобное вместо SQL.
или C# / vb.net для MS SQL Server :)
Я думаю, что OP означает, что альтернативой написанию всего кода его базы данных непосредственно в коде его приложения является либо вызов хранимых процедур, либо введение уровня разделения между кодом его приложения и базой данных с использованием ORM, такого как Hibernate, но да, они очень разные вещи.
Использование хранимых процедур позволяет хранить SQL в одном месте отдельно от кода приложения. Использование Hibernate позволяет полностью избежать написания SQL и обеспечивает объектное представление реляционной базы данных.
Какой путь вы выберете, во многом зависит от приложения и ваших предпочтений.
Я не думаю, что вы хорошо разбираетесь в хранимых процедурах.