Coldfusion Login

[ProjectedSurplus]

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?? Or am I not understanding a necessary step (ie before I try converting these examples to the aforementioned).

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?)

[Newsgroup_User]

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.

[ProjectedSurplus]

Thanks, it's much as I figured but fwiw, with my (albeit limited) knowledge of sql I'd rather write <cfqueries> and even stored procs. As you say, they are more complex in theory but IMHO much better for implementing an MVC type of architecture/organization (not that I am expert in either).

I did think that stored proc offer performance benefits vs. ad hoc sql but perhaps this is more to do with the sql tranaction being pre-compiled vs it being cached (now that I think about it -- though I might be mislabelling some of the terms.)

Thanks again though

[Newsgroup_User]

ProjectedSurplus wrote:
> I did think that stored proc offer performance benefits vs. ad hoc sql but
> perhaps this is more to do with the sql tranaction being pre-compiled vs it
> being cached (now that I think about it -- though I might be mislabelling some
> of the terms.)

Possibly, or a misunderstanding the nature of pre-compiled versus
cached. SQL code can be written so that it takes full advantage of
pre-compilation using the <cfquery...> tag. Just as stored procedures
can be written so that they do not.

Albeit if one is thinking in terms of stored procedures, one is probably
developing code in a manner that facilitates pre-compilation. Just that
it is not *guaranteed* just by slapping CREATE OR REPLACE PROCEDURE
around any old SQL code.

[ProjectedSurplus]

Thanks, I will research a bit more on stored procs you describe.

Do you have any thoughts on this issue I ran into:

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=3&threadid=1398834