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

From: Joe Weinstein (joeNOSPAM_at_bea.com)
Date: 01/26/04 

Date: Mon, 26 Jan 2004 11:39:42 -0800
To: Daniel Morgan <damorgan@x.washington.edu>

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.

Relevant Pages

  • Re: choices regarding where to place code - in the database or middle tier
    ... > write code that used to belong in the middle tier and store it in the ... DBMS vendors, even in benchmarking their products in the standard and artificially ... and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. ... accent as an independent middle tier to handle the logistics to make it one ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middle tier
    ... > write code that used to belong in the middle tier and store it in the ... DBMS vendors, even in benchmarking their products in the standard and artificially ... and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo. ... accent as an independent middle tier to handle the logistics to make it one ...
    (comp.lang.java.programmer)
  • Re: choices regarding where to place code - in the database or middletier
    ... >> and a DBMS doing what it does best, even if in a proprietary way. ... done in the in the middle tier, in addition to or instead of in the DBMS, whether ... functionally do, but because of the radical efficiencies a middle tier offers, ... Oracle to include it in what they would desperately want to make an Oracle-only ...
    (comp.lang.java.programmer)
  • Re: choices regarding where to place code - in the database or middletier
    ... > from selling that middle tier but I completely disagree. ... server is not a thin client. ... I do believe that no bytes should leave the DBMS ... so it queried the DBMS for a list of the countries in Europe hundreds of times ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middletier
    ... > from selling that middle tier but I completely disagree. ... server is not a thin client. ... I do believe that no bytes should leave the DBMS ... so it queried the DBMS for a list of the countries in Europe hundreds of times ...
    (comp.lang.java.programmer)