no-database-triggers
Keep behavioral logic in application code, not database triggers.
Why
Under a single-writer application architecture, triggers hide writes and state transitions from engineers reading application code and make the behavior difficult to exercise through ordinary unit-test seams. Triggers may still be appropriate for approved multi-writer integrity or audit needs.
Fix
Use a declarative database constraint where possible or explicit transactional application behavior; use an exact SARJ114 suppression when an approved database-owned invariant requires a trigger.
Examples
CREATE TRIGGER update_timestampBEFORE UPDATE ON callsEXECUTE FUNCTION set_timestamp ();ALTER TABLE childADD CONSTRAINT child_tenant_fk FOREIGN KEY (organization_id, parent_id) REFERENCES parent (organization_id, id);Formerly: no-create-trigger