Comparison of DB2 and Oracle?

[Rhino]

One of my friends, Scott, is a consultant who doesn't currently have
newsgroup access so I am asking these questions for him. I'll be telling him
how to monitor the answers via Google Newsgroup searches.

Scott has heard a lot of hype about DB2 and Oracle and is trying to
understand the pros and cons of each product. I'm quite familiar with DB2
but have never used Oracle so I can't make any meaningful comparisons for
him. He does not have a lot of database background but sometimes has to
choose or recommend a database to his clients.

Scott has enough life-experience to take the marketing information produced
by IBM and Oracle with a grain of salt and would like to hear from real
DBAs, especially ones who are fluent with both products, for their views on
two questions:

1. What are the pros and cons of the current releases of DB2 and Oracle?

2. What other sources of *independent* information are available to help
someone new to databases choose between DB2 and Oracle?

This is *not* a troll and we don't want to start a flame war! Scott just
want some honest facts to help him decide which product is best at which
jobs.

--
Rhino

[DA Morgan]

Rhino wrote:

Nobody's looking for a free ride. He/we just wanted to hear from people who
had used BOTH products to see what their pros and cons were. He/we also
wanted recommendations about good independent sources of reviews of these
products. That's exactly what I asked for.

Rhino

And exactly what you are not going to get as I haven't found a single
post from anyone that believes you. It is absolutely impossible for the
situation you presented to be true.
--
Daniel A. Morgan
University of Washington
da******@x.wash ington.edu
(replace 'x' with 'u' to respond)

[Mikito Harakiri]

Hans Forbrich <ne*******@telu s.net> wrote in message news:<h3Scd.182 05$cr4.15935@ed tnps84>...

...functionalit y that I see required in many
apps such as: workflow, message queueing, replication, subqueries, direct
http request/response capability, security, backup/recovery, admin &
management tools, job scheduler (akin to cron, but inside the DB), DB
initiated callouts to OS shared libraries, DB initiated mail & page, DB
initiated TCP calls, and so on.

I alway wondered what is the true value of those bells and whistles.
Let's not forget that RDBMS essentially is a SQL execution engine, and
everything else should be judged from the perspective how well does it
fit into that primary purpose. Therefore, let's go through your list
itemized:

1. "workflow". What exactly is this? A bunch of boxes connected with
arrows with some state flowing through them? A very rudimentary
execution environment, if you ask me: no composite data structures, no
exception handling, no debugger, or other things that we take for
granted in any decent programming language today. Does workflow scale
when comlexity increases? And finally how does workflow fit into SQL
execution? I bet any seasonamble programming would prefer to deal with
business logic in a conventional programming language rather than
workflow.

2. "message queueing". Isn't message queue just a table? If it is,
then wouldn't it be easy to leverage SQL interface instead of goofy
PL/SQL API?

3. "http request/response capability". Isn't apache no longer a part
of default server installation in 10g?

[Hans Forbrich]

Mikito Harakiri wrote:

Hans Forbrich <ne*******@telu s.net> wrote in message
news:<h3Scd.182 05$cr4.15935@ed tnps84>...

...functionalit y that I see required in many
apps such as: workflow, message queueing, replication, subqueries, direct
http request/response capability, security, backup/recovery, admin &
management tools, job scheduler (akin to cron, but inside the DB), DB
initiated callouts to OS shared libraries, DB initiated mail & page, DB
initiated TCP calls, and so on.

I alway wondered what is the true value of those bells and whistles.
Let's not forget that RDBMS essentially is a SQL execution engine, and
everything else should be judged from the perspective how well does it
fit into that primary purpose. Therefore, let's go through your list
itemized:

The value is simply in having a wheel around that doesn't need to be
re-invented and maintained.

No matter how much one explains these away with "isn't it just ...",
developers always seme to be reinventing these "justs". What you call
"bells and whistles" seem to be a base requirement in 90% of the projects
I've seen in the past 3 years - only the developer's don't realize the
bells are already there so they either build or buy a completely new set.

If that wasn't true, JMS, MQ Series Queuing and Workflow (oh, sorry - it's
WebSphere now), and the like would not have a reason for being.

Or are you saying - let's get back to commoditizing the SQL engine so we can
recover some of the revenue from these capabilities? Or continue stretching
project timelines to accomplish stuff that already exists? <g>

/Hans

[Mikito Harakiri]

"Hans Forbrich" <ne*******@telu s.net> wrote in message
news:%8xdd.2250 6$cr4.15445@edt nps84...

No matter how much one explains these away with "isn't it just ...",
developers always seme to be reinventing these "justs". What you call
"bells and whistles" seem to be a base requirement in 90% of the projects
I've seen in the past 3 years - only the developer's don't realize the
bells are already there so they either build or buy a completely new set.

Not all technologies are created equal. How much added value is there? Does
that "framework" really simplifies a lot to be worth considering?

If you want something that seems to be needed in 90% of the cases, then I
can sell you "business process coordinator" framework. You have to be
critical about its capabilities, though. It would take you just 2 years to
learn it, as it is quite messy yet. And after that you might discover that
you'd probably be better off just programing your task instead of wasting
your time trying to master a technology that has no clear definition.

To repeat, what exactly workflow is doing? Does it really save any
development time, compared to traditional programming? Does it scale when
business logic becomes more complex?

The argument that they have it because their comptitors have it is nonsence.
Sure when you read a survey of competing RDBMS you see the table with all
features listed. Clearly, nobody wants to see their product with the least
number of check marks in that table. My perspective on this: if users are
really that stupid to draw conclusions from such a table, then they deserve
the product they've got.

[Jim Kennedy]

"Serge Rielau" <sr*****@ca.ibm .com> wrote in message
news:2t******** *****@uni-berlin.de...

DB2 UDB for LUW does not have page locks.. Only row and table level

Doesn't it still have a problem with dynamic SQL such that it locks the plan
table so people who need to bind programs with the database have to wait
until the transaction competes. Thus if one issues dynamic SQL and doesn't
commit for several minutes it will prevent (serialize) those programmers
from binding their programs with the database.
Jim

[Noons]

mi************* ****@yahoo.com (Mikito Harakiri) wrote in message news:<8a******* *************** ***@posting.goo gle.com>...

I alway wondered what is the true value of those bells and whistles.
Because you reject that they can be useful?
Let's not forget that RDBMS essentially is a SQL execution engine, and
Most definitely not. That is a file system. A *database* (that is what the
"D" in RDBMS stands for) is not even necessarily a SQL execution engine:
it could be an execution engine for many other languages. And then there
is the *relational* bit attached to it: the "R". IF you don't know what that
means and what it can do *way beyond* SQL itself ever will, then there
is no point in going there. Just use it as a "SQL engine". While others laugh.
everything else should be judged from the perspective how well does it
fit into that primary purpose. Therefore, let's go through your list
itemized:

Your primary purpose is totally wrong. You don't need a RDBMS,
you need only a SQL engine. Obviously, you can do everything
else the database can do, yourself, and better. What can I say?

[michael newport]

Daniel,

in Ingres I wrote 4GL, in Oracle I write PL/SQL
in Ingres I wrote SQL, in Oracle I write SQL
in Ingres I ran an overnight batch from a Unix cron job, in Oracle I
schedule a dbms_job
in Ingres my results went to a database table, in Oracle my results go
to a database table
in Ingres I wrote a user parameterized report, in Oracle I write a
user parameterized report
in Ingres I ran the report with a system call, in Oracle I use Oracle
Reports server (with all its nasty bugs)

Ingres is free, Oracle is not

did I miss something ?

Regards
Michael Newport

[Serge Rielau]

I have never heard of such a problem and if it ever existed I would
consider it a bug.
Checking....

Cheers
Serge

[Serge Rielau]

Noons wrote:

mi************* ****@yahoo.com (Mikito Harakiri) wrote in message news:<8a******* *************** ***@posting.goo gle.com>...

I alway wondered what is the true value of those bells and whistles.

Because you reject that they can be useful?

Because often they are not useful, or priceworthy, for a given specific
application. I think a core point of this, carefully flame free, thread
so far has been that on eneeds to know ones requirements to knwo which
"bells and whistles" are needed in a specific case.

Let's not forget that RDBMS essentially is a SQL execution engine, and

Most definitely not. That is a file system. A *database* (that is what the
"D" in RDBMS stands for) is not even necessarily a SQL execution engine:
it could be an execution engine for many other languages. And then there
is the *relational* bit attached to it: the "R". IF you don't know what that
means and what it can do *way beyond* SQL itself ever will, then there
is no point in going there. Just use it as a "SQL engine". While others laugh.

Uhm.. while splitting hair one must be careful not to cut ones fingers.
A database is a repository. Its just sits there. Quiet and dumb.
It's that MS (management system) part that does all the work. To the
best of my knowledge neither Oracle nor IBM are in the business of
selling databases.
Now that R correlates, for all major RDBMS that I know, quite well with
SQL as it's access language. Do you know of other languages commonly
used in an RDBMS? Yes, there could be, but there aren't.
Now products have a tendency to evolve beyond the original purpose.
All major vendors support procedural extensions of some sort which are
more or less interacting with the relational engine.
And different vendors have different opinion on how many extensions to
the core should be part of that core RDBMS or stay components to be
added on.
Each his/her religion I 'spose. In the end RDBMS integrate with other
middleware and apps. Be it as the killer product or a component of one.
There is a lot of bloat going on in the market (and I'm not excluding
any vendor)
and that's where the open source products come in...

everything else should be judged from the perspective how well does it
fit into that primary purpose. Therefore, let's go through your list
itemized:

Your primary purpose is totally wrong. You don't need a RDBMS,
you need only a SQL engine. Obviously, you can do everything
else the database can do, yourself, and better. What can I say?

He may be part of a significant part of the customer base for RDBMS.
Not everyone needs a Winnebago. Some folks just want to commute to
work... Mind you that doesn't make Winnebagos bad

Cheers
Serge

[Serge Rielau]

OK, here is the deal:
When you execute a dynamic statement which depends on table T.
DB2 will hold a usage lock on T until the end of the transaction.
So noone will be able to alter T (in a non-trivial way) until this
transaction is over.
An alternate design would be to release the lock after usage.
However in the interest of keeping the cache fast the capturing of locks
needs to be minimized. Schema evolution is considered a much rarer (more
rare??) event than cache-hits

Does that answer the comment?

Cheers
Serge