Actually, the argument here goes both ways.
On one hand, you could code all your queries into stored procedures. In
this manner, database operations typically end up performing faster than
they would with inline ColdFusion <cfquery> statements. However, if you
want to port your ColdFusion code to a different RDBMS (i.e. MS SQL Server
to Oracle), then you'll likely have to re-write all the stored procedures
per Oracle's standards. Additionally, if your ColdFusion developers do not
have access to directly modify the stored procedures (sometimes only the DBA
will have these rights), then making a change to a database call now
involves more people and typically takes longer to complete.
On the other hand, you could code all your queries into the ColdFusion code.
In this manner, the queries will not run as fast, but any developer with
access to change CFML code with also have direct rights to change database
calls - eliminating the possible bottleneck mentioned above with getting a
DBA involved. However, now if someone wants to port the application to a
different language (i.e. ASP, PHP, Perl, whatever) or perhaps build an
add-on application that points to the same database, you've now got to
re-write all that database business logic in the new language or the new
application.
That said, as a developer you really have to weigh this against what best
suites your needs. Perhaps you're dealing with a low volume site on a
hosted server where you don't have rights to create/update stored
procedures. In that case, it makes more sense to build your database logic
in-line with <cfquery> statements. However, if you're dealing with a
high-traffic site with tons of simultaneous users and have rights to
create/update stored procedures (in addition to the knowledge of how to
actually write them), you'd probably be best off writing your database logic
into stored procedures.
Either way, if you shift the RDBMS or the language of the application,
you're going to run into some need to change large portions of logic -
whether it's in stored procs or it's in ColdFusion code.
Just my $0.02,
-Tyson
-----Original Message-----
From: Dave Feltenberger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 4:44 PM
To: CF-Talk
Subject: RE: shopping cart / online store
The problem with using stored procedures is that if you decide to switch
databases, you have to re-write all of them because almost all database
vendors use different stored procedure code and structure. By writing the
queries in the program itself (included as a query file or in the actual
file, whichever), you're not quite as locked into the database - as long as
you're using a relational database that supports SQL standards and you write
standard SQL, you should be ok to plug and play databases as you please -
stored procs screw that all up.
Another problem with putting too much business logic in stored procedures is
that you put too much strain on the database if the site is hit hard - I
worked on a site that gets upwards of a million hits a day (www.casio.com)
and using stored procedures to do too much business logic would have bogged
down the database servers far too much to make it worthwhile. Instead, we
load balanced it all onto several really fast ColdFusion servers and they do
the business logic.
-----Original Message-----
From: Fuon See Tu [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 5:29 PM
To: CF-Talk
Subject: RE: shopping cart / online store
Coding wise, you better use a real good methodology (gotta do that at all
times anyways :P ). Net(fo'got the name) uses fusebox as said on their
site. Database wise, you better depend a lot on stored procedures and
triggers :) makes things a lot easier and faster. I started working with
ASP last week, and passing data back and forth from the DB is a nightmare
since I am so used to coldfusion's so very easy query thingamajig. But the
ASP project I was updating really relied on stored procedures, and updating
it was simple! Although passing variables and such to the stored procedure
was still more of a headache than using CF's super dee duper stored
procedure param tags =). Stored procedures are your friend!
Try to code your site to make the code updated easy. Try not to spaghetti
code, and all that stuff they taught u in programming basics. As far as
functionality is concerned, think about how cool you want this application
to be, then consider if it's worth the time and money. Then think think
about how you want the clients to set up a store, and lay out things
logically.
>From: "Megan Cytron" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: CF-Talk <[EMAIL PROTECTED]>
>Subject: RE: shopping cart / online store
>Date: Wed, 29 Aug 2001 16:57:17 -0400
>
> > Hello
> > Does anybody know of a good resource for planning,
> > developing, and building
> > an online store front with ColdFusion?
> > Including search capabilities, credit card transactions, etc.
> >
>
>Web Monkey has a pretty basic CF shopping cart tutorial that
>could give you an idea of how to implement simple shopping cart
>functions:
>
>http://hotwired.lycos.com/webmonkey/99/49/index4a.html
>
>You can also find a lot of information on different CF shopping
>cart issues in the CF forums
>(http://forums.allaire.com/coldfusion/) and this list's archives.
>
>I think the first step would be to decide between client
>variables, session variables and database storage (or some
>combination of the three).
>
>
>Megan
>[EMAIL PROTECTED]
>
>Alpha 60 Design Shop
>http://www.alpha60.com
>phone: 202-745-6393
>fax: 202-745-6394
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
