RE: Migration from ORACLE 9i to MySQL - Nguyen, Phong - com.mysql.lists.mysql

9 messages in com.mysql.lists.mysqlRE: Migration from ORACLE 9i to MySQL

From	Sent On	Attachments
Nguyen, Phong	28 Jul 2005 09:41
Johnson, Michael	28 Jul 2005 10:56
SGr...@unimin.com	28 Jul 2005 11:24
Scott Hamm	28 Jul 2005 11:40
Warren Young	28 Jul 2005 11:40
Martijn Tonies	29 Jul 2005 00:41
Nguyen, Phong	29 Jul 2005 05:02
Nguyen, Phong	29 Jul 2005 05:10
Sid Lane	29 Jul 2005 07:59

Subject:	RE: Migration from ORACLE 9i to MySQL
From:	Nguyen, Phong (Phon...@disa.mil)
Date:	07/29/2005 05:10:25 AM
List:	com.mysql.lists.mysql

Thank you for your input,

V/R,

Phong

-----Original Message----- From: Martijn Tonies [mailto:m.to...@upscene.com] Sent: Friday, July 29, 2005 3:41 AM To: Johnson, Michael ; SGr...@unimin.com Cc: mys...@lists.mysql.com; 'Nguyen, Phong' Subject: Re: Migration from ORACLE 9i to MySQL

Shawn, others,

Maybe the US Air Force has an unlimited budget but the rest of us do not. It seems to me that they "powers that be" in Nguyen's shop have made a decision (rational or not, you know how some managers are) to move away from a PREMIUM-priced package like 9i to something that can perform comparably to 9i but at a small fraction of the cost. Calling it an "8th grade toy" makes you sound uninformed of what MySQL is really capable of.

Sure MySQL may have a few fewer "bells and whistles" than Oracle but if you don't need to rely on all of the gee-whiz and just need fast, stable data storage and retrieval, MySQL is an excellent choice. Besides, most of those "fancy things" in the premium databases can be duplicated or nearly duplicated using very little client-side code. Of the things that cannot be run in client-side code (I am particularly thinking of stored procedures and triggers) those are coming in 5.0.x.

Do you think NASA, Yahoo, and a host of other Fortune 100 companies made a mistake by using MySQL in their production enviroments? I don't.

It all depends on the application it's used for.

MySQL 5 is a very nice release - once stable, of course - but in some regards, it has a long way to go.

No doubt, many Oracle applications can be converted to MySQL, but this is because those applications don't use Oracle well enough :)

IMO, duplicating something that can, could and should be done on the server in client code is a step backwards. In earlier days, the "foreign key constraints" like described in the MySQL documentation was a shining example of ignorance on the part of the documentation writers. Luckily, InnoDB has foreign key constraints.

But there are plenty of other applications that cannot be converted to MySQL, no doubt, some run fine and dandy... We use MySQL here in the office as well, but use InterBase and Firebird for others...

The right tool for the job makes the whole difference.

With regards,