Let me repeat: I'm in favour of triggers. I think they're necessary to
keeping a sane database. But I don't find this design easier to
maintain than the clunky RLA design.
Buck,
Thanks for the feedback. I'd like to better understand your concerns. My
previous comment about improving the readability of code had more to do
with creating source members and modules with clearly delineate a
separation of concerns. Say "module A" handles DB I/O while "module B"
handles data validation and business rules.
The source members are more readable because there is less code to read,
and the separation of concerns is clearly delineated. Edit "module A" if
you need to change DB I/O logic. Edit "module B" if you need to change data
validation and business rules. Or edit both modules by opening them in
side-by-side tabs.
Here is a DB I/O module. It encapsulates CHAIN, WRITE, UPDATE, and DELETE
procedures:
http://code.midrange.com/6c917d5af1.html
The DB I/O module traps errors using op code extenders and assists with
percolating errors back to procedures which implement the UI.
Here is the corresponding module for handling data validation and business
rules:
http://code.midrange.com/ee85fb606a.html
Both modules perform cleanly separate roles. The DB Event Handler runs
behind a trigger, checks the validity of field values and returns
appropriately formatted error messages.
Your concerns appear to pertain more to complexities which might arise by
implementing cascading triggers. And how visible (or invisible) that code
might be to application developers.
midrange.com
