Is there any mileage in doing this with triggers? I have a _very_ legacy system which needs caching adding. Rather than dig through the code to invalidate the cache every time a record is updated/deleted in 20+ tables, I am thinking that being able to listen to the SQL executed and invalidate the cache based on the tables involved would be a clean approach.
But not found any way to make that possible - yet.
1. Triggers have an 8000 byte limit. I ran against these limits pretty quickly
2. You need to attach the trigger each time you create a new table. With this you can set and forget
One of the motivating factors for not using triggers is that the implied overhead is very significant. By logging changes separately which triggers the write volume is roughly doubled, and the overhead of insertions is much much higher (a lot of fast/bulk path can't be used, the trigger processing needs to be performed).
Very true what you mention about trigger overhead. Also you don’t get guaranteed atomicity