All good stuff which I agree with (to the extent that my understanding of such things means that "agreeing" has any weight behind it!).
Definitely issues I will weigh up when appropriate situations call for it, thanks :-) Now all I need to do is find the extra ten-or-so hours in every day to research all the stuff I want to. Adam -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Watts Sent: Friday, 9 July 2004 11:16 a.m. To: [EMAIL PROTECTED] Subject: RE: [CFCDev] data abstraction layer ideas? - diff db's (was Seria lization of CFCs) > 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). Yes, you can do that in most enterprise databases. > 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. There are a lot of variables that can go into these sorts of "which is faster" questions. In some cases, passthrough SQL will be faster than stored procedures, while in other cases the reverse will be true. In general, it's been my experience that stored procedures usually work faster than passthrough SQL for the types of applications on the specific database platforms I'm using. > 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. I would argue that the separation attained by using CFCs for data access logic isn't equivalent to the separation attained by not having any SQL in your application code at all. Of course, the difference may be insignificant to many people. > 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. That is certainly a disadvantage of using stored procedures. > 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. Well, sure, but that SQL would be buried in a giant pile of other code, more or less. It's a lot easier to rewrite an application without embedded SQL statements, I think. In addition, what if you wanted to have multiple applications sharing a common database? In that case, you'd have to ensure that the SQL in both stayed the same, unless you simply removed that code and put it in the database itself. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
