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: Trying to decide whether to support DB2 or Oracle

Re: Trying to decide whether to support DB2 or Oracle

From: Larry <lsedels_at_us.ibm.com>
Date: Mon, 07 May 2001 19:32:37 -0400
Message-ID: <3AF73095.C03CBF27@us.ibm.com>

Marc,

I don't know what the product plans are in terms of the requirement for the "C" compiler. But there is another side of this that I respectfullly submit you are completely ignoring: performance. How would an interpretive SQL stored proc perform vs. an IBM SQLPL "compiled" stored proc, for a reasonably complex stored proc? I really don't know ... I'm just asking. But I'll bet that the compiled stored proc would tend to perform better.

In this industry, there are two sides to every story ... there is always a cost. In this case, ease of use vs. performance maybe? Nothing's perfect. If you try hard enough, you will be able to find fault with any database, even Oracle.

The Nomad wrote:

> > You should have the commands "GET ROUTINE" and "PUT ROUTINE". That way,
 you
> > compile the STPs once on your build machine (A), run GET ROUTINE, copy the
> > file created there to the machines (B) you want to install the STPs on,
 run
> > PUT ROUTINE ON B and you're all set. No need for a C compiler on B.
>
> The problem with that is the need to have every machine-type we need to
> support. We aren't a huge development shop with access to every machine and
> processor that DB2 runs on. This isn't feasable, practical or even
> reasonable. The whole idea of an RDBMS language like SQL is to be platform
> agnostic, at least within a single RDBMS. As I said in an earlier post on
> this topic - for Oracle, the whole process is simple - I create DDL, Stored
> Procedures, Stored Functions, Etc. in a single text file. I pass that text
> file to a server (any Oracle server, it could be running UNIX, it could be
> running Windows, it could be running anywhere for all I care) and it creates
> the tables, indexes, stored procedures, stored functions, packages,
> everything. No C compilation, no anything. It just works. It is ubiquitious.
>
> For DB2, not really. This is a severe design flaw in my opinion. You might
> as well require a C++ compiler for everything. How big would the customer
> pushback be if your messaging was "to create a table, please install a C++
> compiler". Ohhhh - you want an Index? First, install a C++ compiler, and
> we'll take care of that for you.
>
> Ludicrous? Maybe. But that is the deployment solution DB2 is providing ISV's
> who need stored procedures for application performance and isolation. If it
> is getting fixed in a future fixpack, great. I can hardly wait. But posting
> that the problem is "already addressed" is misleading. It is *not*
> addressed. It is kludged perhaps if you have heterogenous machine-to-machine
> deployments. But in this day, what ISV has that? There is no work-around.
>
> Marc
Received on Mon May 07 2001 - 18:32:37 CDT

Original text of this message

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