And that's why I don't understand your recommendation to Rob. He stated
his language of choice is PHP and then you lambast him for not responding
to your RPG approach with database triggers.
In regards to me lambasting Rob, I don't know him personally, but his
conversational tone strikes me a person who might appreciate a blunt
response. I don't mean any offence.
In regards to my recommendation about placing data validations, RI
constraints, and business rules behind triggers - I don't think there
should be any apologies.
This is not my idea. It has been around for a long time. It was explained
more fully to me about a year or so ago. The more experience I have gained
in the mean-time has solidified my opinion that this is worth striving for.
I would recommend the same architecture regardless of the database in
question, regardless of the language in question, IBM i or otherwise.
I don't know the background of Rob inheriting an enterprise-class database.
But since he has, I will stick with my recommendation that the best tools
and interfaces be used to ensure its integrity and protect it from
malicious access.
Regarding the idea of keeping Rob entirely in PHP, I suppose it would be
nice if PHP ran "in the database", but I don't see that as viable, if even
possible.
I understand the need for triggers/queues/etc. But in his case a better
approach (or at least what I'd recommend) is to queue a request back into
his PHP app via REST webservice that determines whether an email should be
sent.
Sorry, I don't understand that. I'd welcome further explanation. What would
be providing the web service and what would be consuming it? What would be
the purpose of the queue? Would the PHP Toolkit be required to access the
queue?
midrange.com
