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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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