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

From: Joe Weinstein <joeNOSPAM_at_bea.com>
Date: Mon, 26 Jan 2004 11:39:42 -0800
Message-ID: <40156CFE.3040905_at_bea.com>


Daniel Morgan wrote:

> Joe Weinstein wrote:
> 
> <snipped>
> 

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

Coolness.

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

No, the original is correct, that I council *against complete DBMS INDEPENDENCE*. The 'IN' is intended, and in the original post. I also council against complete DBMS-specificity, or even using the DBMS for everything it can do. For instance, a system design could include DBMS-specific code in the middle tier and in the DBMS to invoke and enact such proprietary things as it's stored procedures. On the otherhand, such aspects as transactional control, *some* data caching, and real end-user request handling and multiplexing of DBMS requests might be best done in the in the middle tier, in addition to or instead of in the DBMS, whether solutions to these needs were available from the DBMS in a standard or proprietary way.

    In the case of simply getting the most out of a DBMS in a simple DBMS-centric benchmark, Oracle itself chooses not to use the DBMS itself for all it could functionally do, but because of the radical efficiencies a middle tier offers, they choose to use a third-party middle tier. You should be sure that the performance benefit of such an independent middle tier must be radical for Oracle to include it in what they would desperately want to make an Oracle-only show. Further, it must be a valuable, non-trivial task to make and support such a middleware product, else Oracle would have made it's own long ago. Received on Mon Jan 26 2004 - 20:39:42 CET

Original text of this message