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

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Mon, 26 Jan 2004 10:06:11 -0800
Message-ID: <1075140307.522781@yasure>

Joe Weinstein wrote:

>> And just because at some point years later they MIGHT decide to change
>> to another product where they can once again write mediocre code with 
>> minimal performance and scalability.
>>
>> On one hand you toot BEA's horn by saying the Oracle gets its best 
>> performance with BEA. Then you advise removing the beast's teeth and 
>> claws.
>>
>> Sounds a bit schizophrenic to me. Buy my product because it makes 
>> Oracle blazingly fast ... but when you implement it ... don't take 
>> advantage of any of those features that make it blazingly fast.

>
>
> I'll try to make it clearer for you. An example of what DBMSs do well,
> but proprietarily,
> are stored procedures. I say "use them, to the extent, and in the way a
> DBMS implements
> them, rather than try a lowest-common-denominator SQL92-from-client model".

We are in complete agreement so far.

> As to what the DBMS does not do well, and which BEA (or any other excellent
> middleware manufacturer) does do well, I need say nothing. Ask Oracle's
> best core performance engineers why they use BEA in their top TPC-C benchmark.
>
> There is no dicotomy in a system that contains middleware doing what it
> does best
> and a DBMS doing what it does best, even if in a proprietary way.
>
> Let me know if you have any more questions,
> Joe Weinstein at BEA

Unless I interpret the above as meaning you've changed your mind I am lost as to your original intent when you wrote that you counsel against complete DBMS dependence. Seems like you've changed from "dependence" to "INdependence". Was the original a typo or did I misunderstand you?

-- 
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 Mon Jan 26 2004 - 12:06:11 CST