Re: choices regarding where to place code - in the database or middletier

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Wed, 21 Jan 2004 06:56:00 -0800
Message-ID: <1074696893.709317@yasure>

Joe Weinstein wrote:
>
>
> Daniel Morgan wrote:
>

>> Render under to database everything you can do in the database and let 
>> the middle tier do what it does best ... fail-over, load levelling, 
>> and serving up the front-end.

>
> Sure, and and
> mindless
> repeat queries, and acting as a transaction monitor/controller to get
> the best
> performance out of the DBMS, etc. Otherwise you should explain why
> Oracle chooses
> to use BEA as middleware when it simply tries to demonstrate it's own
> performance
> potential in TPC-C benchmarks.

There are things a lot more important than benchmarks and performance. We all know all RDBMS vendors do whatever they need to get the magic number ... the one better than the competition.

But all of what you refer to as "protecting the DBMS from uncontrolled ad-hoc connections" as middle-ware is not valid on its face. You put up the best middleware tool you can and then give me SQL*Plus, MS Access, whatever ... and all of your protections are null and void. The middleware only protects from those connections routed through the middleware ... and it is for that reason specifically we see far too much data corruption.

>> Try tuning all that rotten SQL coming from those fat front-ends 
>> sometime and you will understand why those here that have experience 
>> with PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.

>
> Well, sure. I have done so, in fact. The stupidities are legion. Many of
> these
> applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to
> 'client-server' by simply swapping in row-by-row cursor fetches to the DBMS
> instead of the previous ISAM call. Intelligent client-server architecture
> (as I've said) puts the sawmills where the trees are, not in the client.
> However,
> client-server is dead, at least to the extent that now everyone in the
> company
> or the internet may want the info in the DBMS(s), and transactions now
> involve
> serveral DBMSes and other resources. Thats where the middle tier makes it's
> contribution, and depending on what's done, and what degree of concurrency,
> isolation, atomicity etc that particular data requires, it can now find a
> profitable home in either the DBMS or the middle tier, at least as a cache.
> As an example from the Baan suite, they really did architect their
> application
> so it queried the DBMS for a list of the countries in Europe hundreds of
> times
> a day for each user. A current state-of-the-art application would have a
> generic
> browser as one of it's clients, and in such a case, the middle tier is
> ideal for
> caching the list of the countries in Europe, and making is available to all
> clients, and given the political instability in Europe, maybe refreshing
> it's
> list once daily from the DBMS? It saves a lot of DBMS cycles...
> IMHO...
> Joe

I'm not arguming the valid of your company's product or middleware. Only the fact that data security and integrity must be protected at the RDBMS level. That you may layer a little more on top is fine but anyone depending on it rather than the RDBMS is begging for problems.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Wed Jan 21 2004 - 08:56:00 CST