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
> >> 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
> > 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,
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
My thoughts:
Database development questions? Check the forum!

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