No future for DB2

[rkusenet]

This article is very bleak about future of DB2. How credible is the
author. http://www.eweek.com/article2/0,1895,1839681,00.asp

[Serge Rielau]

Noons wrote:

Serge Rielau apparently said,on my timestamp of 31/07/2005 1:15 AM:

The only platform Oracle was never ported to, is AS/400
There *is* a God!...

Nope - well at least that ain't proof - AS/400's interfaces are not open.
Aside if Oracle ran on OS/400 it would be running on DB2..
Now that would be funny indeed.

Hmmmmmm.... I conclude that db2/as400's interfaces are not open.
Now, there is an interesting twitch to the argument
the product is the same across all platforms...

<g,d&r>

An bogeyman kept alive by the Oracle posters here (looking for a
something to rub on for lack of better topics?)
Show me where an IBMer has claimed the product is the same across these
platforms.
Note that many customers of IBM develop on DB2 for LUW (i.e Windows) and
then deploy on DB2 for zOS. Apparently the compatibility is close
enough, especially since the clients (CLI, JDBC, ...) are indeed the
same codebase.

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Paul]

DA Morgan <da******@psoug .org> wrote:

If her (ahem.. home...) movies were part of the default Oracle
install, I'd reckon that Oracle sales' figures would go up! Any chance
of a job with Oracle marketing?

With apologies ...
It would certainly make a good marketing image for ease of installation.

Not to mention market penetration! Could be a head's up for the sales
department, but they might just blow the opportunity!!!

Paul...

--

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2,

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.

Furthermore, as a courtesy to those who spend
time analysing and attempting to help, please
do not top post.

[Paul]

"rkusenet" <rk******@hotma il.com> wrote:

So creating index on the FKY column
should be automatic when creating the FKY constraint.

Not necessarily, at least AIUI.
Say one has a table person with fields title, first_name, last_name,
add1, 2, 3.....
Now, you have title as a lookup table - it's a lookup into the title
table.
Now, the vast bulk of your inserts will be Mr. or Ms., so you will get
a skewed index and performance can suffer if you have an index, rather
than doing a simple table scan.

I know that this has been an issue with Interbase in the past which
automagically created (AIUI, one can now change this). I'm not sure of
the performance implications for Oracle, but it is AFAICS, one good
reason for not *_automatically _* creating an index.

Paul...
--

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2,

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.

Furthermore, as a courtesy to those who spend
time analysing and attempting to help, please
do not top post.

[Larry]

Bob Jones wrote:

No, partitioning is not included in DB2 Workgroup Edition. You can't even do
simple replications in DB2 without purchasing a separate product.

We have been discussing here primarily DB2 for Linux/UNIX/Windows right?
This is not true. Replication is included free-of-charge with DB2 WE and
with DB2 ESE.

Larry E.

[bka]

the 1530 people who posted something about tpc in comp.databases:

http://www.google.ca/search?hs=TwZ&h...G=Search&meta=

?

[Buck Nuggets]

> How could running recovery drills be easier in DB2 than in Oracle?

db2 has less moving parts to worry about

If I were to compare Oracle and DB2, ease of use or support would be the
last thing come to mind. The overall difference is so minor. Anybody with
slightly different experience would disagree with you.
once again, less moving parts. less stuff to manage. of course,
sometimes those extra parts given oracle flexibility that's useful. at
least theoretically that's the case. In my opion, it's also much less
forgiving - in which every single configuration change is preceeded
with a backup, and even shutting down the database can be a pain.
That's something that just doesn't seem common in the db2 world - to do
backups before every change. Talking about 9i here and v8 btw.
No, partitioning is not included in DB2 Workgroup Edition. You can't even do
simple replications in DB2 without purchasing a separate product.

Last I checked, Workgroup Server Edition (WSE) costs $999 + $250 / user
in the concurrent or registered model. It also supports:
- replication
- multi-dimensional clustering (very similar to oracle partitioning)
- 64-bit instances
- up to 4 cpus
This means you could *easily* build a 2 TB data warehouse on db2 for
under $1500 in licensing costs. And yeah, mdc is different than
oracle's partitioning - lacks oracle's nice partition management. But
is very easy to work with, and is great for performance. And of course
you could also use union-all views - which are more similar to Oracle's
partitioning. This capable is also *free*, and can be combined with
mdc if you wish. And then if you want to take the next step and move
into DPF (spanning multiple servers), either of these techniques can be
*combined* with that partitioning strategy.

And how much does partitioning cost / server for oracle? $10,000? so,
what are we looking at here? $1500 for db2 vs $40,000 just for oracle
partitioning - not even including the base product?

Note that buying just the vanilla database doesn't get you all the data
warehousing bells and whistles that oracle & db2 can offer. Then
again, those features are expensive and of debatable value anyway.

[Bob Jones]

>>

No, partitioning is not included in DB2 Workgroup Edition. You can't even
do simple replications in DB2 without purchasing a separate product.

We have been discussing here primarily DB2 for Linux/UNIX/Windows right?
This is not true. Replication is included free-of-charge with DB2 WE and
with DB2 ESE.

I am talking about replicating data from DB2 on z to DB2 on LUW.

[Mark A]

"rkusenet" <rk******@hotma il.com> wrote in message
news:3l******** *****@individua l.net...

The project I am working on has been developed by UK folks and we are
customizing it for this Canadian customer. I too got a feeling that those
guys are experts only in SQL Server.
Their concept of a RDBMS seems to be weak. For e.g. in SQL Server
one can create a Foreign Key without creating an index. In fact index
creation on the FKY columns is a separate process. Same in Oracle
and DB2. What the UK folks never realized is that almost all the time
a FKY column is joined with PKY column for Query (otherwise why
would it be a separate table). So creating index on the FKY column
should be automatic when creating the FKY constraint.
When I joined the project, one of the first fire I had to fight in the
testing phase was locking. SQL server use to do table scan when it
can't find matching index and that pretty soon escalated into locking
and deadlock problem.
ISOLATION LEVEL - well most of them don't even know what it is,
let alone it is.

I am beginning to wonder whether being a full time DBA is a
dying profession left for old fogies like me.

The subject of foreign keys and indexes has been discussed in the Oracle
newsgroup recently.

Not all foreign keys need (or should have indexes). Some foreign keys are
merely connected to code tables that are used to make sure a valid value is
used, and they are never joined. The example used in the Oracle thread is
division_code on sales transaction table that relates to a division_code
table with only 3 rows (divisions).

Having an index on the foreign key for division_code would slow down inserts
on the sales transaction table, and would never be used for queries
(cardinality of 3 is too low for a RDBMS to use this index for queries),
except for the extremely unlikely event of someone trying to change or
delete a row in the division_code table.

So creating an index on a foreign key should not be automatic.

[rkusenet]

"Mark A" <no****@nowhere .com> wrote in message
news:d9******** ************@co mcast.com...

The subject of foreign keys and indexes has been discussed in the Oracle
newsgroup recently.

Not all foreign keys need (or should have indexes). Some foreign keys are
merely connected to code tables that are used to make sure a valid value is used, and they are never joined. The example used in the Oracle thread is
division_code on sales transaction table that relates to a division_code
table with only 3 rows (divisions).

Having an index on the foreign key for division_code would slow down inserts on the sales transaction table, and would never be used for queries
(cardinality of 3 is too low for a RDBMS to use this index for queries),
except for the extremely unlikely event of someone trying to change or
delete a row in the division_code table.

So creating an index on a foreign key should not be automatic.

While I agree with you, I would add that for code lookups like Title (Mr,
Mrs, Ms)
I would rather go with a check constraint than a FKY. Anything with a low
cardinality
and known static values should be handled in a check constraint. At least I
would.

[Mark A]

"rkusenet" <rk******@yahoo .com> wrote in message
news:3l******** *****@individua l.net...

So creating an index on a foreign key should not be automatic.

While I agree with you, I would add that for code lookups like Title (Mr,
Mrs, Ms)
I would rather go with a check constraint than a FKY. Anything with a low
cardinality
and known static values should be handled in a check constraint. At least
I
would.

The fact is that almost all modeling tools will show a foreign key
relationship to the lookup table as part of 3rd normal form. When the DDL is
generated by the tool, it will generate indexes for these relationships
automatically (incorrectly IMO). The result is poor performance on inserts
of the dependent table.

The result is that many schemas have way too many indexes that will never be
used, and of course invariably there are at least a few indexes missing.