Re: Trying to decide whether to support DB2 or Oracle

It might be something on their to-do list. AS/400 is getting rid of the C-compiler requirement with the next release (due to come out May 25). Many DB2 features start on one platform and eventually get to the rest. I don't know if that'll be the case here, but it'd be a good idea.

Larry wrote:
>
> 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 Tue May 08 2001 - 16:43:54 CEST