Re: Database Server Vs. Application Servers - Processing Location

An important question. I am performance-biased. The first thing to avoid is shipping mass quantities of raw data out of the DBMS to be processed in any sort of external program. Don't treat the DBMS as a dumb file system. This is the lowest common denominator use of DBMSes, and makes it easier to swap out DBMS implementations, but it fails to make optimal use of the DBMS's primary design goal: relational set-based processing power. Use the DBMS to manipulate raw data whenever possible. Export only the data needed for presentation, reports, and necessary for transactions that are external to the DBMS.
    This is counter to the goal of being DBMS-independent, to the extent that a significant amount of application intelligence may end up in stored procedures, which are alway proprietary in their construction, but the operational value of acceptible performance is often greater in real terms than the strategic but rarely enacted ability to swap out DBMS implementations.

    However, for user interface, data caching, and transactional preparation and control, as well as the ability to integrate other resources, you do want an application server tier. Client-server is dead. You absolutely don't want the DBMS hobbled with lots of per-user simple repeat queries and multi-message transactions. The DBMS is like the cook/chef in a restaurant. You will never scale if you have the customers interracting directly with him. Make it so he's doing what he does best, and is asynchronously loaded by an efficient middle tier (the waitresses?) that keep the input queue filled and orders, and also manage the output queue, interrupting the cook only for exceptions.

   This is just a quickly considered post, leaving plenty of holes to argue and fill, but I hope it helps.
Joe Weinstein at BEA

Burton Peltier wrote:

> Just wondering what others opinions are on this subject...
>
> Within our company, there are some who think in-house developed applications
> should be architectured such that there is no dependence on the underlying
> database server software - the database server should only do CRUD
> (create,read,update,delete) processing.
>
> This might at first seem sensible to some, I think there are way too many
> "gray areas" to say the above should be a "standard" that must be adhered to
> or have permission to do differently. I am guessing this is some people's
> intent.
>
> Some people spend way too much effort trying to not "tie" themselves to 1
> database vendor and don't take advantage of features and functionality (in
> Oracle for our company), at a significant loss either by lost functionality
> or performance or "writing their own way". Or, they do things like put hints
> in the SQL to tune and are "tied" anyway.
>
> Note: I can see where a software vendor should/has to try and work this way.
> But, this does not seem to make sense for a commercial company like ours.
>
> --
Received on Wed Aug 20 2003 - 09:34:26 CDT