Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: choices regarding where to place code - in the database or middletier

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

From: Joe Weinstein <joeNOSPAM_at_bea.com>
Date: Thu, 29 Jan 2004 08:51:19 -0800
Message-ID: <40193A07.7080301@bea.com>

>
> We are going to have to end this one with a total disagreement. Having
> spent more than 33 years in IT and more than 15 of them with relational
> databases I have yet to ever see an example of:
>
> "Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
> specific functions that optimize or implement security, performance, and
> scalability (and other stuff)"

I can't understand your inability to grok this. If a product is written using DBMS-vendor-specific functionality in a way which makes the product unportable to another DBMS, it is DBMS-specific and dependent on that DBMS.

>
> and
>
> "Complete DBMS independence means that a system is not bound to a given
> DBMS, because it uses only the functionality offered by the DBMS that is
> accessible via DBMS-neutral syntax"

A simple-minded product that connected to any JDBC-accessible DBMS, and sent only fresh SQL queries is an example. Not powerful but certainly DBMS-vendor independent.

> What you suggest is a logical impossibility.

How did I do this time? What logical failure is there in my simple examples above?

> In Oracle, for example, there is no better place to put code than in a
> package; for numerous reasons. No other database vendor has the concept
> ... therefore throw packages away.
> In Oracle and DB2 the best way to do numering is with a sequence. SQL
> Server and Sybase don't have them so throw sequences away. Of course SQL
> Server and Sybase have autonumbering that Oracle doesn't have so throw
> autonumbering away too. Guess we won't have any surrogate keys except by
> wrapping your own ... now that's generic. All we need to do now is
> recompile for every operating system.

No! You seem to be working on false presumptions. Repeating ad nauseum, I advise against complete DBMS-independence. Using oracle packages would not impose a severe enough problem with the generality of the DBMS client part of the application for me to suggest that they not be used. If you need numbering, you have to do it DBMS-specifically, or wrap your own. I don't understand about the recompile comment. Java, for instance doesn't need it. The other point is that there *are* some things that you should not have the DBMS do. The reason may be that the functionality requires too much specificity in the product outside the DBMS, or it may be simply be because the part of the product outside the DBMS can do it better.

> Sorry Joe ... but your attempt to construe development to sell your
> company's product is a great way to do some things. Creating high
> performance scalable databases isn't one of them. Not once has Oracle
> won a benchmark contest with BEA using generic code. No one else will
> either.

No one ever stated that the current best practice is generic code. You are busily beating a horse that only you brought to the race. The big point you can't address, is that even using all Oracle's capabilities, generic or proprietary, it goes into standard benchmarks with middleware to make it go fast. This means that there are some things you don't want the DBMS to do whether they are generic or not. Even if some of these things are usually thought of as central or integral to a generic DBMS product.
Proof:

     http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all Received on Thu Jan 29 2004 - 10:51:19 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US