> > Storage engines are unique to MySQL? yes. Is that good? YMMV. Most
> > of the purported benefits can be achieved with Oracle's features
> > without the compromises of balkanised storage engines. You're right,
> > they're not offered by Oracle, or anyone else ... there's a reason no
> > other database bothers with storage engines - they got storage right
> > the first time :-) (ooh ... the flames I'll get for that :-) ). Sure,
> > non-volatile data in a MyISAM table can be read at the speed of light,
> > and handle the odd insert. Funnily enough, a text file has the same
> > properties. They both suck for non-trivial concurrent transactions.
> > I'd suggest taking a look at parallel DML, nologging, MVs,
> > partitioning, direct-path insert, appended insert, RAC, ASM, ASSM,
> > etc. etc. etc. in Oracle for more perspective
> LOL - an entertaining read!
Entertaining? I feel to see the humor in his post.
> 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.
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Database development questions? Check the forum!