Wednesday, March 8, 2017

SQL triggers antipattern

If application A updates application B and then application B turns around and updates application C with database triggers in a reactive way (I will cry out when you touch me), this is bad. Do not daisy chain application updates. Ideally there is a pub/sub process for allowing both B and C to drink up what's new at A. Anymore when you ask yourself "When would I want to use a trigger?" it's hard to justify it. I guess you could have database to database updates if records are kept in two sister tables in two sister databases, and I guess you could have a logging table that gets updated from triggers when other tables are touched.

No comments:

Post a Comment