No flame wars, please!

We're planning a move from a non-relational system to
a relational system. Our choices have been narrowed to
Oracle and DB2. Since we're moving from non-relational
to relational, then we're not currently using any
relational-type operators. So I expect the end result to
use simple, SQL standard commands and queries.

The question: At the SQL standard level is there any
appreciable difference between Oracle and DB2.

Example: I know that Oracle has cascading deletes. We're
not using them now so I don't expect to use them with the
new system.

Thanks.

Mike

OK ... so you cross-post to comp.databases.ibm-db2 and
comp.databases.oracle with a subject line of "db2 vs. Oracle", and then
you request no flame wars? I won't hold my breath!

At the SQL level (as you put it), DB2 employs ANSI SQL ... and is the
only RDMBS vendor to employ a stored procedure language that complies
with ANSI's PSM standard.

Larry

Mike wrote:

Mike <mikee (AT) mikee (DOT) ath.cx> wrote


The simple answer is no: each have their own strengths & weaknesses,
but these tend to be nuances and each are otherwise very ansi sql
compliant.

The complex answer is it depends: on exactly what you want to do with
this database. I've had to make quite a few purchasing
recommendations in the past, and to be honest, sql features has never
been a deciding factor (between major commercial products). Licensing
costs, vendor strategy, vendor/product viability, solution
managability, skills availability, third-party support, performance &
scalability - these were the factors that typically influenced the
decision the most.

DB2 & Oracle are very competitive in my opinion. Oracle has more
mindshare, third-party support, and features than DB2 does. DB2 is
slightly more primitive, but also simpler and cheaper. DB2 also has
some very high-end scalability capabilities if you're in the data
warehousing world.

Coming from flat files, vsam, ims/db, or mysql these db2 & oracle
probably look about the same. But once you get much closer and start
working with them the differences loom large. ;-)

Buck Nuggets wrote:
I too am responding from the Oracle usenet group but my comments will
be as non-inflammatory as possible.

A. Based on what you posted either product could meet your needs as the
information you provided is nearly as substantial as a vacuum.

B. What internal skills do you and your team have? You indicate no
prior knowledge of SQL. Do you think you are going to pick up either
of these products without classes and books? Have you looked for local
classes? Have you looked at the book resources available? Have you
looked for local expert resources to support and mentor your team?

C. What operating systems are you and your team familiar with? Do you
expect to be running this on Windows? Linux? some flavour of UNIX?
mainframes?

D. What are your security requirements? Are you expecting to host a
web site?

E. What are your anticipated transaction volumes in terms of number of
transactions? Number of simultaneous transactions? Transaction sizes?

F. Does what you are building require a front-end? GUI? Web?
Client-Server? What tools? What connection mechanism?

I could list a good 20 to 30 more without even beginning to exhaust
the basic criteria that are the minimum set from which your decision
should be made.

Absent these answers anything you get in a usenet group will be worth
what you paid for it.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

which choices did you look at ?

did you consider Ingres ?

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

at the sql syntax level, there's not much difference Ov10 vs. DB2v8.

on the other hand: oracle and db2 use diametrically opposite
concurrency
mechanisms. oracle is said to require more husbanding than oracle.
on
the other hand, 390 db2 is just as needy. oracle is said to be a dog
on
the 390 (at least by blue folk). oracle is pretty much the same on
any platform. db2 is pretty much different on any platform. oracle
has
most of the mindshare on *nix (except AIX, natch), and it's largest
install segment. it doesn't exist (IIRC) on AS/400.

there are studies which show Total Cost of Ownership to be higher with
oracle. ditto db2.

your biggest effort, should you choose to do so (most COBOL/VSAM folk
don't), is defining a relational structure which balances the
concurrency
stuff you get free in a (R)DBMS with the existing code base, which
was/will be doing it too. you'll need to decide. if you use the DB
concurrency stuff, you should remove it from the code. if you leave
it
in the code, you'll get it from the DB anyway, and performance could
be
anywhere from a little worse to in the toilet. depends.

hire a consultant. one that has documented experience with systems on
your platform and oracle and db2 on that platform. it's your only
hope.

Comments in-line.

Perhaps in the past. Certainly not with 10g.

I absolutely agree. And make sure the consultant is equally familiar
with both. A carpenter will favour a hammer even when confronted with
a sheet metal screw.

--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

Daniel Morgan <damorgan@x.washington.edu> wrote

You're using a wrong approach to determine the RDBMS that will suit
your need. The kind of application you're thinking of running should
be the first concern. Are you goning to be running OLTP, DDS or
datawarehouse application. I don't think Oracle will bet UDB, Sybase
or SQL Server when it comes to OLTP application. As far as
datawarehouse is concern, Sybase has a specific product that is design
for that specific application called Sybase IQ.

The mistake organization make when picking database platform is the
same kind I am seeing from the approach you're taken. If you running
mission critical application, then you should be concern about backup
and recovery. Oracle backup and recovery is too complicated otherwise
they won't need a 4 days training seesion on the topic. It takes a
couple of hours to teach the same function in other platform. My point
is that you have to think of what is important in the application
you're running.

Not according to a lot of published benchmarks. And not according to
the owners of the biggest OLTP systems on the planet.

But then what does Sybase have to do with the OP's question? The
OP specifically stated a choice between DB2 and Oracle and most likely
either would work just fine. So comments about SQL Server and Sybase
are irrelevant.

BTW: Oracle backup and recovery unless you are still working with some
Paleolithic version consists of a few mouse clicks in OEM. So your
comments indicate little but ignorance about the product.

--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

Flame wars .... here we come! <sigh>

Ollie wrote:

Oracle is as good, if not better, with OLTP as the others.

Like any environment, you have to understand it properly to be able to use
it properly.

Statements like "I don't think Oracle will bet UDB, Sybase or SQL Server
...." generally are based on "I learned how to do it efficiently on 'x' but
those principals don't apply to 'y' therefore 'y' is bad."

Of course, Ollie is using a traditional 'more competitor names is relevant'
tactic, conveniently forgetting that Sybase sold their soul to Microsoft by
giving them what is now SQL Server.

Oracle Backup and Recovery is not difficult - you do need to understand it
though. Since backups are really only relevant for recovery, the course is
designed to give a large number of scenarios in recovery that you actually
practise so that you do not need to 'practise' or look like a dodo to
mamangement when a crash actually occurs.

Besides, the course includes other items, such as Oracle Networking.

My point is that Ollie is attempting to use irrelevant information, or pure
FUD, to prove his point.



Religion in software, like ignorance, is bliss.

/Hans