Your thinking on access points and validation are correct. Based on the response below, would you suggest using CGI/mod_perl to run the web-end? Am I correct in thinking I'll need to update to 4.1 for transactional support in order to make this work appropriately? Finally, any suggestions for forward compatibility of a host of PERL files running this system into TRIGGER statements in 5.x? In other words, you think I'm better off organizing the data by-query or by-function. I'd guess by-query given the use of TRIGGERS in the future. Feedback? KC
-----Original Message----- From: Roman Neuhauser [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:05 PM To: Primaria Falticeni Cc: Kerry Colligan; MySQL LIST Subject: Re: Triggers # [EMAIL PROTECTED] / 2003-06-17 21:28:12 +0300: > From: "Kerry Colligan" <[EMAIL PROTECTED]> > > I see that 5.x will support triggers. Does anyone have any advice for > > implementation of triggers on the DB? I will need to be able to utilize > > them from web applications AND from command-line type interface. Any > > suggestions welcome at this point. (RH 7.3, MySQL 3.23.56 presently) > > Why don't you use PHP or ASP functions on the server-side in Web page code. > They act like a trigger and you don't need MySQL 5.0 for them. Remember that > you can benefit from the both servers: MySQL and Web server. I think the OP has made himself clear enough: there'll be two access paths to the database, and command line use with ad-hoc queries is most likely to cause RI damage; triggers are a way to avoid this risk. I would however (probably) prefer hiding the tables behind a set of stored procedures. Usually, they have a few advantages: * they don't slow the RDBMS down by triggering the... errr... triggers * they're stored "precompiled", so you avoid the parser overhead of ad-hoc queries * you can make them the only access point to the data, allowing you to know (or trust :) that there'll be no random problems of the "oh wait, I forgot to put WHERE in that UPDATE!" variety -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
