List:General Discussion« Previous MessageNext Message »
From:Martijn Tonies Date:July 31 2007 12:28pm
Subject:Re: Migration from Oracle to MySQL
View as plain text  
> >> 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

Thread
Error compiling on Solaris 6Giulio Troccoli26 Jul
  • Re: Error compiling on Solaris 6mysql26 Jul
    • RE: Error compiling on Solaris 6Giulio Troccoli26 Jul
      • Migration from Oracle to MySQLSrikalyan Tangirala26 Jul
        • Re: Migration from Oracle to MySQLGrant Allen27 Jul
          • Re: Migration from Oracle to MySQLMark Kirkwood30 Jul
    • Re: Migration from Oracle to MySQLMartijn Tonies26 Jul
    • Re: Migration from Oracle to MySQLMartijn Tonies30 Jul
      • Re: Migration from Oracle to MySQLMark Kirkwood31 Jul
    • Re: Migration from Oracle to MySQLMartijn Tonies31 Jul
RE: Migration from Oracle to MySQLRajesh Mehrotra26 Jul
  • RE: Migration from Oracle to MySQLSrikalyan Tangirala26 Jul
  • RE: Migration from Oracle to MySQLsliebman26 Jul
  • Re: Migration from Oracle to MySQLLuca Ferrari27 Jul