Re: Reinventing triggers?
Been there. At first I had the same opinion as you. But no, these kind of systems are not triggers 2.0 because triggers have a number of drawbacks:
1- Trigger code is database dependent. It is much easier to drop a module of this type already tested by someone else than try to develop DB specific code to push a message into some kind of message bus. For each DB engine and version. And I've been in places with three different DB engines in at least two different versions each.
2- Depending on the DB, not all operations invoke triggers or there are specific commands to disable triggers during execution of other statements. This is usually done for performance reasons, and as such...
3- Withou rigorous inspection and review (and even with those by accident), trigger code easily can become a bottleneck, something you do not want when you're interested in your DB transactions being commited as quickly as possible.
Triggers are wonderful when you have no other means of expressing a business domain constraint and want to enforce it at the database level (those that say that these constraints can be enforced at the app level have a special place in hell filled with junior external consultants banging directly on a database violating all business constraints and repeating "but it works for my use case") Triggers as the foundation of a data bus are one of those ideas that look good in your head but become headaches on the medium term. That's why these kind of tools exist.
Biting the hand that feeds IT
