On 10/2/2015 3:52 PM, Nathan Andelin wrote:
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.
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.
My apologies for misconstruing the original post. This is what I was
focussed on when I replied: 'The idea is to move data validation and
business rules "out of applications" and "into the DB", meaning that the
logic is run in (or behind) triggers. So "rules" and "business logic"
cannot be bypassed. That ensures DB integrity, and makes the logic more
readable and maintainable.'
-snip-
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.
Exactly. As we move business logic out into triggers, it gets less
visible. Here's a contrived example of work I need to do:
Use case:
Customer gets an email with a '10% off next order' coupon for entering a
birth date with us. Customer clicks the link, uses web portal to set
birth date.
Implementation:
Add a trigger to CUSTMAST which detects a new birth date and generates a
credit for the customer as well as sends an email confirming the credit
is on file. My work is done, whether the customer responds to the
email, a printed avert or an upsell on the phone with customer service.
Business logic can't be bypassed - Sweet!
Or is it? What other actions occur when the birth date changes?
Web RPG program does I/O to CUSTMAST, updating BIRTHDATE.
CUSTMAST trigger fires, notes change in BIRTHDATE, updates RESCANCREDIT
table.
RESCANCREDIT trigger fires, contacting the credit bureau to check
customer credit validity. This updates credit score.
Credit score trigger fires, recalculating how much credit to extend to
customer. This looks through pending orders, in case customer exceeds
credit limit. It finds one large order, which is placed on credit hold.
Credit hold fires a trigger which sends an email to customer service
that the customer needs orders reviewed due to credit issues.
Customer gets a call from Customer Service and becomes Not Happy.
How could this situation be avoided? What tool is going to trace the
cascade of triggers from birth date to credit hold? In Ye Olde Dayes,
the web RPG program would have performed all of this logic, or it would
have explicitly executed sub-procedures which perform that logic, or it
would have called an I/O wrapper sub-procedure which in turn would have
executed other sub-procedures which would have performed that logic. I
could see - in the source code - the exact chain of events that
transpires when I update CUSTMAST. Yeah, it was ugly, but I could
follow the flow from source member to source member.
With triggers in the mix, that analysis is not nearly as obvious -
especially if the triggers are written in SQL, and not an HLL like RPG
or Cobol. If an HLL implements the triggers, there's at least a chance
a cross reference tool will pick up the reference. If the triggers are
LANGUAGE SQL, I'm not sure there are any tools which will tell me that.
My current strategy is to look at each I/O operation, check for
triggers. For each trigger, find each I/O operation. For each I/O
operation, check for triggers. And so on.
I kind of like wrapping I/O in sub-procedures, but in terms of finding
these cascades, it's another level I need to analyse. At least with
sane sub-procedure names, it's easy to figure out what sub-procedures I
need to investigate. Or is it? How many sub-procedures inside my web
RPGLE program fire d1ChgDettRec? Simply scanning my RPG source for a
given file name doesn't work because the file isn't referenced in the
web RPGLE source code - it's buried down in a sub-procedure whose source
is elsewhere.
I need to be really, really clear: I'm not ranting against triggers or
sub-procedures! I love and use them both - for the exact reasons you
cite. Because you are exactly right - a database without internal
integrity is pants.
What I am arguing /for/ is better tooling to be able to visualise the
effects of a proposed change. Web Navigator is pretty good, and it's
getting better, but triggers have added quite a lot to the analysis
phase of my job. Which plays right into the hands of my vanity; I like
to imagine I'm a thinking creature :-)
midrange.com
