geno

This is food for thought.
I am working with a real strong c++ programmer, but not real strong on web
work.
He made a comment that The application side should be where the most work
should be in a web application; NOT THE DATABASE.
I was taught different.
I realize that Having the Database and the application server on the same
hardware is not the best setup, but many people do that. I have always tried
to make the database do the majority of the work. (calling Stored Procs,


Cold Fusion applications?

Thanks for the feedback,
Geno

cletus d. lee

In article <bnk65k0cov@enews1.newsguy.com>, genegodsey@hotmail.com
says...


I will bet he is not a real strong SQL language person either. (If all
you have is a hammer, everything looks like a nail)

The Web is the 'Presentation Layer' Business processes do not belong
there. The Application Layer can be both on the client and the server.
Traffic from the Application server to the database server cost in
performance Even worse if the traffic is to the user's client where
ever it may be in the ether. Minimizing this traffic by putting part of
the work on the database server. (effective use of Stored procs etc.)
will be realized on the performance of the overalll application.

charliek

I would basically agree. The database operations that need to be done
in a web request is the performance bottle neck. If you can possibly
elliminate a query with business logic, or cut down on the number of
time you issue a query with caching you will be speeding up your
application. However using stored procs is a good practice instead of
issuing these queries in a cfquery tag. The stored proc will be
compiled in the database, and you will have less information to
transmit from the webserver to the database. Using views is not the
best way to speed up performance, however it is probably better then
issuing the same sql statement many times.

Basically I would say that both the application side and the database
should be used where appropriate. Each application will have a
different mix of application side vs. database work.

Just my 2 cents,

Charlie

jim davis

To me the lines are getting fuzzier and fuzzier.

Generally (and very simply) speaking you have the following:

1) The data layer: usually a database (but could be other things)

2) The business logic layer (how to use the data).

3) The presentation layer (how to display the data and interact with the
user).

The simple fact is that most tools in our scope can effectively cover at
least two of those layers (usually one and two or two and three). I think
that you're talking about the business logic layer (the "rules" layer) which
hosts most of the actually functionality of the app.

A case can be made for all sides. For example:

"Business logic should be built the database"

Stored Procedures and scriptable SQL allow for rich business logic designs.
The DB is optimized for this kind of work and it makes sense to centralize
this information in one place. By doing this any application that can
access the DB can leverage the standardadized data access and business
logic. Traditionally data platforms are less volitile than application
platforms - so it makes sense to place our important rules on the most
stable platform. You also free up the web server resources for more complex
user interfaces. It just makes sense to place your logic in the database.

"Business logic should be in the application server"

Application tools are more flexible and more full featured than even the
best scriptable databases. In addition you can separate and specialize
business logic to mutliple hardware platforms to improve performance and
fail-over. By incorporating all business logic in the application server
you remove database-system specific dependencies allowing you to easily
apply your logic to multiple database platforms or syndicate it to multiple
locations. It just makes sense to place your logic in the application
server.

I general I personally like to place my logic in the application layer - but
to further separate that from the presentation layer (in CFMX CFCs have made
this so much easier). You will get people that are die hard one way or the
other. There's a large contingent of "SQL for Data, Java for Logic, CF for
looks" (replace "Java" with "C++" and "CF" with "JSP", "ASP", etc for other
variations).

In short I'm not sure there is a "right" answer. Every project will be
different. For example we have more database folks at the office than CF
folks and CF isn't the only language using the data (ASP, JSP, PowerBuilder,
etc) so it makes sense for us to stuff lots of business logic in the
database. However I'm also building another application which may need to
be converted to multiple databases - so the less in the DB the better...

Jim Davis

geno

Thanks for your input.

Geno

geno

Great stuff,
Thanks,
Geno