macromedia.coldfusion.cfml_general_discussion
[Top] [All Lists]

Re: Coldfusion Login

Subject: Re: Coldfusion Login
From: Ian Skinner
Date: Fri, 10 Oct 2008 15:40:45 -0700
Newsgroups: macromedia.coldfusion.cfml_general_discussion

ProjectedSurplus wrote:
This might be a stooooopid question but all the Coldfusion/Dweaver LOGIN examples/tutorials/code wizards seem to entail:
 FORM.CFM page >>> submits to ACTION.CFM >>> <CFQUERY> to
database >>>

 whereas I understand that for coldfusion 7/8 (with mysql 5 fwiw) cfcs and
stored procedures offer benefits from security to code organization. Is true??
Yes there are benefits to using CFCS and Stored Procedures. But there
is also, usually, more complexity. Thus most examples and tutorials
take a simpler approach to not overwhelm the person being exposed to the
concepts for the first time.
Especially since many of these examples,tutorials and wizards have
existed longer then ColdFusion has had CFCS, though probably not longer
then it has had stored procedures.
 On a related note, what are the performance implications of say <cfinsert> vs.
say <cfquery> with INSERT INTO . . . (and/or vs. stored procedures though from
what I understand the stored proc will have greater speed due to database
cacheing etc -- thus should it not be used for non-cache needed commands?)
Well for <cfinsert...> versus <cfquery...> it is usually convienance
over capability. If one gets right down to it, there must be some
microscopic performance hit while ColdFusion runs some code deep in its
heart to build the SQL string to send the database with <cfinsert...>.
But other then that, the main difference is that it usually does not
take long before a developer is doing code that is too complex to handle
with <cfinsert...> and thus learns to write his own SQL code. Once
learned there is little need to switch back to <cfinsert...> when it is
just as easy to write ones own simple SQL code as have ColdFusion do it.
As for ad hock SQL in <cfquery...> tags over Stored Procedures. There
is again a complexity image here. Stored Procedures are perceived as
being more complex, though again, they really aren't. There is the
complexity of having code in more places, which usually is not a bad
thing. But for very simple projects may be overkill. Also, the CF
developer may be a junior position that does not have permissions to
create Stored Procedures in the database, so just uses what access he
has until such a time as a project is important enough to refactor into
using procedures.
But none of this has any bearing on what is or is not cached. And there
is not correlation between using ad hock SQL with <cfquery...> or Stored
Procedures based on the 'non-cache' need of database code.



<Prev in Thread] Current Thread [Next in Thread>