Martijn Tonies wrote:
>> 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).
>> 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).
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