>> I'm a SP bunny, so might be missing something). > 'm not sure what an SP bunny is, actually.
I am a novice when it comes to stored procedures. >There are several reasons why you might want to use SPs for all of your data access if possible. First, you can more effectively secure data access if you use SPs exclusively Can you set DB perms up so *only* SPs can be executed, and not pass an SQL query to it via a DB driver? That makes sense (I've never really looked @ that side of things). > Second, you may see performance benefits even with simple operations on certain platforms. Third, you will achieve a better Someone else mentioned that. I had heard (on this mailing list, even, I think? Maybe not) people had done some analysis of this, and <cfquery> was more performant than <cfstoredproc> for analogous (albeit basic) querying. Obviously even if this is the case, it's a CF-centric issue, but I'm framing my question from the CF POV. Given where we are ;-) >separation of data access logic, See this is the one I don't buy. Well I do, but it's an incomplete notion to me. The separation is a Good Thing, don't get me wrong, but if can equally be achieve by having the tier in a CFC (or a CFM, or a custom tag, or any old thing). It's the fact that it's separated that is the key point here. >and the ability to reuse that logic from other applications if desired. Very true, but it depends on your perspective. Our software is designed to work on one development platform (CF), but to work on multiple DB platforms. SO it's beneficial to have a CF query doing "SELECT COL FROM TABLE", than having to maintain several different SPs. And even if we ported the software to [some other language], the ONE thing that would tay the same would be the "SELECT COL FROM TABLE" thing. >Of course, there are some disadvantages to using SPs, but I usually find them outweighed by the advantages. They're certainly something I want to have a chance to have a fiddle around with, and to see their capabilities, that's for sure. Adam ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
