Should triggers be used with ORM?

Question

C++ / C#

I started to understand what ORM is and how it works. Previously, I used ADO to interact with the database, on the side of the database I used triggers and stored procedures. If I'm using an ORM, does that mean all logic should move into the application and I shouldn't use triggers? Or am I misunderstanding something? Explain, please.

Answer 1

Of course, by their very nature, ORMs are designed to help keep all the business logic in the application itself, not in the database. In general, this approach scales better, and, in addition, allows you to change the DBMS with less effort in case of a strong change in project requirements.
However, there are a number of tasks where triggers may well work in tandem with an ORM library. This is NOT business logic, but rather support logic. I can immediately remember the following:
- support for the integrity of denormalized data - recalculation in the trigger of "redundant" values, such as sums, averages, etc. (i.e. those that can always be counted and that are stored solely to improve query performance). In this case, even if someone wants to work with the database without using O / R mapping (for example, perform a couple of samples for analytics), there will be no data mismatch;
- support for chronologicaland audit-tables; it is also logic, in general, independent of the subject area, and often it is NOT mapped in the ORM (especially in the case of audit tables - if the application can still work with history, then the audit is usually needed only in exceptional cases - damage data, database security issues, etc. - and queries on such tables are made manually in the course of investigating the problem).
In EF, using this attribute, you can specify that the value of an entity property is generated by the database itself and EF should not participate in updating it.