Question

I’ve learned a lot about triggers and active databases in the last weaks, but I’ve some questions about real world examples for these.

At work we use the Entity Framework with ASP.Net and an MSSQL Server. We just use the auto generated constrains and no triggers.

When I heared about triggers I asked myself the following questions:

1. Which tasks can be performed by triggers?
   e.g.: Generation of reporting data: currently the data for the reports is created in vb, but I think a trigger could handle this as well. The creation in vb takes a lot of time and the user should not need to wait for it, because it’s not necessary for his work.
   Is this an example for a perfect task for a trigger?

2. How does OR-Mapper handle trigger manipulated data?
   e.g.: Do OR-Mapper recognize if a trigger manipulated data? The entity framework seems to cache a lot of data, so I’m not sure if it reads the updated data if a trigger manipulates the data, after the insert/update/delete from the framework is processed.

3. How much constraint handling should be within the database?
   e.g.: Sometimes constrains in the database seem much easier and faster than in the layer above (vb.net,…), but how to throw exceptions to the upper layer that could be handled by the OR-Mapper?
   Is there a good solution for handeling SQL exceptions (from triggers) in any OR-Mapper?

Thanks in advance

Answer 1

When you hear about a new tool or feture it doesn’t mean you have to use it everywhere. You should think about design of your application.

Triggers are used a lot when the logic is in the database but if you build ORM layer on top of your database you want logic in the business layer using your ORM. It doesn’t mean you should not use triggers. It means you should use them with ORM in the same way as stored procedures or database functions – only when it makes sense or when it improves performance. If you pass a lot of logic to database you can throw away ORM and perhaps whole your business layer and use two layered architecture where UI will talk directly to database which will do everything you need – such architecture is considered “old”.

1. When using ORM trigger can be helpful for some DB generated data like audit columns or custom sequences of primary key values.
2. Current ORM mostly don’t like triggers – they can only react to changes to currently processed record so for example if you save Order record and your update trigger will modify all ordered items there is no automatic way to let ORM know about that – you must reload data manually. In EF all data modified or generated in the database must be set with StoreGeneratedPattern.Identity or StoreGeneratedPattern.Computed – EF fully follows pattern where logic is either in the database or in the application. Once you define that value is assigned in the database you cannot change it in the application (it will not persist).
3. Your application logic should be responsible for data validation and call persistence only if validation passes. You should avoid unnecessary transactions and roundtrips to database when you can know upfront that transaction will fail.