Re: Migration from Oracle to MySQL

> >> LOL - an entertaining read!
> >>
> >
> > Entertaining? I feel to see the humor in his post.
> >
> >
> I thought it was concise and well written, with an undertone of "I know
> I'm swearing in church but...". So yes, I found it entertaining (I agree
> that it was not necessarily humorous or funny).

Ah right :-) ... now I understand.

> >> One advantage of multiple storage engines that comes to mind is that
you
> >> can streamline your setup for different workloads:
> >>
> >> - Innodb/Falcon for non-trivial concurrency workloads
> >> - Myisam for fairly static or bulk-loaded (mainly) read workloads.
> >>
> >
> > MyISAM never really got "finished" as a data storage engine
> > and neither did InnoDB.
> >
> > MyISAM doesn't support referential constraints, so for any serious
> > data storage, it's a no-go area for me.
> >
> > InnoDB, on the other hand, doesn't support Full Text Indices (Search),
> > that's where MyISAM comes into play.
> >
> > That's the problem with the currently available non-alpha storage
engines
> > in MySQL: they just don't cut it.
> >
> >
> >
> While your factual observations are undoubtedly correct, the conclusions
> bear some discussion. In particular for data warehousing constraints are
> not so important - as the ETL process that loads your data typically
> needs to check it anyway - and are often not practical - for instance
> enabling a foreign key constraint on a 10 billion row/10TB fact table is
> gonna just take too long ...(you tend to see "ALTER TABLE ADD CONTRAINT
> xxx ... DERERRED/NOVERIFY" or similar syntax with other database vendors
> to add the constraint but stop it doing anything except being a data
> point for the optimizer).

Data warehousing always requires a slightly different strategy, I agree.

When it comes to database application, I'm always talking about online transaction processing and the like.

> I agree that all the Mysql storage engines need work ... I assume that's
> being sorted (perhaps not as fast as we all would like) by the various
> developers. And just be be clear, the storage engines of most databases
> need work - for instance I work for a company that has used Postgres to
> make a parallel shared nothing data warehouse engine (sounds a bit like
> NDB huh?), and yep, the Postgres storage engine has areas we are wanting
> to improve!

I don't consider the different storage engines in MySQL a "strong point" because none of them do the complete works. Now, if, for example, Falcon gets finished and it does full text indexing, transactions, check/unique/primary
and foreign key constraints, then we're getting somewhere.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle & MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum! http://www.databasedevelopmentforum.com

-- 
MySQL General Mailing List
For list archives: 
http://lists.mysql.com/mysql
To unsubscribe:    
http://lists.mysql.com/mysql?unsub=lists@pantek.com

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek