Re: Database Server Vs. Application Servers - Processing Location

Joseph Weinstein <joe_at_bea.com> wrote in message news:<3F4386F2.411F2C2A_at_bea.com>...

> 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.

Agreed 10000%! I keep having this same discussion with the "architects" where I work. There is simply NO WAY IN THE WORLD that ANY appserver using ANY language can even approach to within various orders of magnitude how fast a RDBMS can process bulk data to produce summary or detail results. Period. And I won't even bother anymore wasting time proving this: done it so many times it's not even funny!

> it easier to swap out DBMS implementations,

I do strongly dispute that claim as well: when was the last time you saw ANYONE swap DBMS implementations, regardless of CRUD being used or not, where it was not a major exercise? Never! And anyone that claims so is simply lying!

> but it fails to make optimal use
> of the DBMS's primary design goal: relational set-based processing power.

EXACTLY!
> 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.
Precisely. Use whatever tools the given RDBMS provides, be they SPs, SQL, internal language, whatever! Get the data processed where it is stored, and displayed where it can easily be manipulated by the user.

> 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.

ABSOLUTELY. The keyword here is "rarely". What is the point of giving up on efficiency and ease of coding to provide a feature that may AT BEST be exercised only ONCE?

Reminds me of cretins that continue to demand everything is "scripted" so it can be "re-used", even the stuff that will NEVER be used more than once! Stupid to the point of hurting...

> This is just a quickly considered post, leaving plenty of holes to argue and fill,

Sure, understood. So is mine.

> Joe Weinstein at BEA
>

Good to see an app server person with a head screwed on the right way!

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Thu Aug 21 2003 - 00:34:44 CDT