Когда не следует использовать ORM и предпочитать хранимые процедуры?

13

Я использую PetaPoco микро-ORM. Работать с базами данных, используя инструменты ORM, действительно очень легко и безопасно, но я ненавижу только дополнительный код. Раньше я помещал большую часть кода в саму базу данных и использовал все функции СУБД, такие как хранимые процедуры, триггеры и т. Д., Которые он создан для лучшей обработки.

Я хочу знать, когда не следует использовать ORM поверх хранимых процедур / триггеров и наоборот.

RPK
источник
6
Лично моя проблема с триггерами (в частности, не относится к хранимым процедурам) заключается в том, что они пытаются «угадать», что произошло «бизнес-действие» из того, как манипулируют данными в БД. Если вы измените столбец ЦЕНА в таблице «СТАТЬИ», то вы не знаете, почему это так. Пользователь только исправляет опечатку? Это уценка? Это специальное предложение, которое длится только один день? Триггеры должны угадать все это.
Иоахим Зауэр

Ответы:

16

ORM (объектно-реляционное отображение) не являются взаимоисключающими с хранимыми процедурами. Большинство ORM могут использовать хранимые процедуры. Большинство ORM генерируют хранимые процедуры, если вы того пожелаете. Так что проблема не в этом.

ORM могут генерировать неприемлемый SQL (с точки зрения производительности), и вам иногда может потребоваться переопределить этот SQL с помощью SQL, созданного вручную. Один из способов сделать это - использовать SP (хранимые процедуры).

В DotNet не используйте хранимые процедуры, если:

  • Если вы не знакомы с хранимыми процедурами (не ваш случай, но включены для полноты).

  • Если вы не хотите вносить слой сложности и разнообразия в ваш проект.

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

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

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

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

Без шансов
источник
2
Я полагаю, что аргумент безопасности связан не с внедрением SQL, а с разрешениями (т. Е. Управлять разрешениями для конкретной хранимой процедуры в основном просто для пользователей, имеющих доступ к базе данных, но управляя этими разрешениями для таблиц, столбцов и ряды либо сложнее, либо невозможны). Тем не менее, аргумент безопасности остается дискуссионным.
Арсений Мурзенко
@MainMa, спасибо за ваш комментарий. Насколько я понимаю, с помощью SP можно снизить риск внедрения SQL-кода, используя параметризованную хранимую процедуру со встроенными параметрами, как предлагается в этой статье: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures
NoChance
2
Хранимые процедуры практически не влияют на уязвимость к SQL-инъекциям. Старые мифы умирают тяжело.
Рог
@Rig 1, спасибо за ваш комментарий, я хочу узнать больше о том, что вы думаете об этом. Мое понимание исходит из этого текста (по крайней мере): «Вы можете предотвратить атаки с использованием SQL Server с помощью хранимых процедур и параметризованных команд, избегая динамического SQL и ограничивая разрешения для всех пользователей». который появляется в msdn.microsoft.com/en-us/library/bb669057.aspx
NoChance
@EmmadKareem Параметризованный sql - это большой шаг в обеспечении безопасности. Я думаю, что этот парень делает разумное дело palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Поиск по нему «Хранимая процедура SQL-инъекция» вызовет много хитов. Всегда полезно дезинфицировать ваши входные данные, и многие платформы предоставляют встроенный способ сделать это достаточно хорошо.
Рог
13

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

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

Везде, где вы кодируете бизнес-логику, ее задача - убедиться, что база данных переходит из одного согласованного состояния в другое согласованное состояние независимо от того, какое приложение вносит изменения . Таким образом, у вас на самом деле есть только два практических варианта - кодировать его один раз в базе данных или один раз в «непроницаемом» слое доступа к данным.

Остерегайтесь интерфейса командной строки dbms, если вы используете «непроницаемый» DAL.

Майк Шеррилл 'Cat Recall'
источник
4
Я сталкивался с несколькими случаями, когда старые SP и триггеры приходилось использовать с новыми приложениями из-за существующих устаревших приложений. Преимущество состоит в том, что эта бизнес-логика должна поддерживаться только в одном месте.
jfrankcarr
Я определенно не отрицаю, что использовалась «одна база данных для их обслуживания», но это в основном дело прошлого, потому что обслуживание становится просто адом, особенно когда нескольким приложениям необходимо поддерживать собственные версии хранимых процессов. Наличие базы данных для обслуживания приложения, которому она принадлежит, является гораздо более современным подходом, поскольку обеспечивает более слабую связь между приложениями и службами.
Флейтер
-1

Простой запрос -> ORM

Сложный запрос -> хранимая процедура

Темная ночь
источник
3
Где комплекс отделяется от простого запроса,
Independent
-2

Триггер должен использоваться как инвариант записи или состоять из жизненно важных бизнес-правил, ИМХО.

Проблемы форм:

  1. Вы должны установить разрешения для таблиц, а не для «действий» (я имею в виду SP)
  2. Чтобы изменить логику вашего решения, вам нужно изменить код внутри вашего приложения, а затем распространить его по сети для клиентов.
Юрий Викулов
источник
-5

Не согласен. Запрос ORM проще, только если вы знаете ORM лучше, чем SQL. ORM приводит к гораздо большему количеству кода, гораздо труднее поддерживать IMO. Единственными, кто извлекает выгоду из ORM, являются акционеры компании, продающей ORM (например, Microsoft).

фантом
источник
1
Жаль, что мнение, выраженное в этом ответе, не подкреплено ни ссылками, ни опытом. В результате это будет бесполезно для читателя, который может наткнуться на «обратное» утверждение, будто хранимые процедуры приносят пользу только поставщикам БД . Заставляет вспомнить , почему руководство в реальных вопросы есть ответы государства: «реальные вопросы есть ответы , а не предметы или идеи или мнения ... »
комар