4 ms·
Except you have the same problem, but are simply moving the complexity from the application to the database. It's not just a single insert trigger. You need one
by developer2 10y ago
Except you have the same problem, but are simply moving the complexity from the application to the database. It's not just a single insert trigger. You need one or more delete triggers. You need update triggers for things like unread or soft delete flags. It's also more difficult to maintain 5-10 triggers at the database level where there are few tools to see how multiple triggers for the same aggregation interact with each other.
The point is you're suffering the same problem. Whether you do it at the application level or the database level, it's a mess.
- nostrademons 10y agoRight, but the point is that by moving it to the database level, you give the applications above it some guarantees about the state of the DB. You can be sure that some other application hasn't gone and written to the DB without firing the trigger. You can be sure that you don't get race conditions from an application not properly using transactions when updating the derived data. And you can be sure that if a transaction is rolled back, the derived fields will still be in a consistent state. It doesn't free you from programming, from reasoning about your code, or from ensuring that this code is free of bugs. But it does free you from worrying about whether the bugs exist in multiple places or whether there are subtle race conditions involved in the code interacting with itself. Whether this important depends on how many applications are accessing the same database. There's a strong argument for one app = one DB, if you can get away with it, and then none of this is relevant. This is not always possible.
- Roboprog 10y agoOther application? There is no other application, old man. What you talkin' 'bout? ... (2 years later) ... Oh, now I get it!