Re: db2 vs oracle
From: Mike <mikee_at_mikee.ath.cx>
Date: Fri, 27 Aug 2004 15:22:22 -0000
Message-ID: <10iukdeajkdl3c4_at_corp.supernews.com>
>> Comments in-line.
>>
>> > 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.
>>
>> Perhaps in the past. Certainly not with 10g.
>>
>> > 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.
>>
>> 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.
Date: Fri, 27 Aug 2004 15:22:22 -0000
Message-ID: <10iukdeajkdl3c4_at_corp.supernews.com>
In article <82f47a3c.0408270444.633be454_at_posting.google.com>, Ollie wrote:
> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1093580524.649947_at_yasure>...
>> Comments in-line.
>>
>> > 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.
>>
>> Perhaps in the past. Certainly not with 10g.
>>
>> > 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.
>>
>> 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.
> > 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.
Thank you and everyone for your opinion. I have DBA'd and developed for most databases out there (Oracle, Sybase, Informix, Unify, Ingres, open source, etc.) except for DB2. I know and understand their strengths and weaknesses. I also very well understand my company's current application and where they want to be in two years. While most find my original question too general to answer, and being general felt I was focusing on the wrong aspects of my needs, I asked the question intentionally and have received the responses I need.
Mike Received on Fri Aug 27 2004 - 17:22:22 CEST