> >> 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/[EMAIL PROTECTED]
