Hooray for stored procedures! >I despite previous debates with other CF`ers, don't like the concept of >Coldfusion handling queries within the CF code. If possible i'd rather
>shift that sort of thing back on to the SQL server (Stored procs) etc, >as this then allows other projects to utilise these queries as well. Handling SQL in CF is a bit slower too! Using procs stops the process of CF parsing the sql, the parameters are typed.. and so on Scott Thornton, Programmer Application Development Information Services and Telecommunications Hunter Area Health Service Phone +61 2 49214193 Fax +61 2 49214191 [EMAIL PROTECTED] >>> ... triggers..... ewww.... MS SQL 2000 easily procides referential integrity without writting triggers yourself.... but yes, triggers can provide some great maintenance support. I prefer adding the "extra" code to the bottom of the insert/update (and sometimes delete) stored procedure however.... >>> [EMAIL PROTECTED] 18/03/2004 9:34:14 am >>> These are my personal thoughts on the matter: A database to me is more of a data holding tank, make sure its running effeciently and if possible use triggers to take care of mundane tasks (ie link table updates/inserts) etc. I despite previous debates with other CF`ers, don't like the concept of Coldfusion handling queries within the CF code. If possible i'd rather shift that sort of thing back on to the SQL server (Stored procs) etc, as this then allows other projects to utilise these queries as well. Furthermore, using the "BatFink" concept, i like the approach of keeping the LOGIC abstract from the DATA, much like you would the entire MODEL from the VIEW. To me this is a sexier approach as you can swap out the DATA side of things (hopefully) with minimal impact on the actual application. I don't know how this will go with "Enterprise" level programmers at large, but to me it seems a cleaner concept to simply leave DB side of things alone - in that keep it as a holding tank, use some SP wherever it seems needed and hell, use triggers for basic concepts like "Link Tables". Nothings more annoying when developing then do an update and then having to do mundane procedures to keep Link Tables up to date. I only wish years ago, i really made more use of triggers in SQL. Probably the overall point is: Use the right tool for the right job and as Sean said, use whats within your skillset and is comfortable. -- Regards, Scott Barnes - http://www.mossyblog.com http://www.bestrates.com.au WALTERS Scott wrote: > imho, the DBMS is the protector of data, hence it should be validating > everything that goes in, and it should perform any associated tasks without > being asked to do it by the app (eg update an article requires incrementing > workflow, writing an audit record etc) > > Basically, multiple apps should be able to hook into the one database and > use it without having to be aware of potentially different validation logic > in other apps. That doesn't preclude validation logic sitting in the app > itself, it just means that ultimately data must be validated by the database > before its acceptable. > > Cheers > > Scott. > > -----Original Message----- > From: Taco Fleur [mailto:[EMAIL PROTECTED] > Sent: Thursday, 18 March 2004 07:15 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: Database programming > > >>I'm really interested in getting the DB to do more work for >>me, but am just wondering about the best way to approach it... >> >>Currently I use the database for very little except storing >>the data... all the logic and validity checking is done in >>the application. I know >>should be using it for more, which is why I'm learning more >>about it now. > > > I still suggest to have it to do everything but the validity checking, I see > that as unneeded traffic to the database. > > > IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
