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>