Использовать ли триггеры совместно с ORM?

Начал разбираться, что такое ORM и как это работает. Раньше для взаимодействия с базой использовал ADO, на стороне базы пользовался триггерами и хранимыми процедурами. Если я использую ORM, значит ли это, что вся логика должна переместиться в приложение и я не должен использовать триггеры? Или я что-то неправильно понимаю? Объясните пожалуйста.
  • Вопрос задан
  • 438 просмотров
Решения вопроса 1
Nipheris
@Nipheris Куратор тега C#
Конечно, по своей природе ORM призваны помочь держать всю бизнес-логику в самом приложении, а не в базе данных. В целом, этот подход лучше масштабируется, и, в придачу, позволяет меньшими усилиями сменить СУБД в случае сильного изменения требований к проекту.
Однако есть ряд задач, где триггеры вполне могут работать в паре с ORM-библиотекой. Это как раз таки НЕ бизнес-логика, а скорее support-логика. Сходу могу вспомнить следующее:
- поддержка целостности денормализованных данных - пересчет в триггере "избыточных" значений, например сумм, средних и т.д. (т.е. таких, которые всегда можно посчитать и которые хранят исключительно для повышения производительности запросов). В этом случае даже если кто-то захочет поработать с БД не пользуясь O/R маппингом (например, выполнить пару выборок для аналитики), не произойдет рассогласования данных;
- поддержка хронологических и аудит-таблиц; это также логика, в общем-то не зависящая от предметной области, и зачастую она НЕ мапается в ORM-ке (особенно в случае аудит-таблиц - если с историей приложение еще может работать, то аудит как правило нужен лишь в исключительных случаях - повреждение данных, проблемы с безопасностью БД и т.д. - и запросы к таким таблицам делаются вручную в ходе исследования проблемы).
В EF с помощью этого атрибута вы можете указывать, что значение свойства сущности генерируется самой БД и EF не должна участвовать в его обновлении.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы