Re: Trying to decide whether to support DB2 or Oracle

It's definitely on our to-do list. We're examining the choices we'd have to make to deliver this in a future release. We won't deliver this as quickly we we delivered Sequence support (i.e. this is bigger than the next fixpak).

Robert Dean wrote:

> 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 Wed May 09 2001 - 00:15:00 CEST