MyISAM remains MySQL’s default choice regardless of
InnoDB being available in it for years.
. . .this suggests that the table types are functionally equivalent.
They’re not. MyISAM doesn’t support transactions, and never will.
Oracle bought Innobase, the company that owns InnoDB,
calling in to question its long-term viability in
Oracle’s competitor MySQL.
MySQL claims they’re going to build a table handler that is
functionally equivalent to InnoDB. I’ve also been hearing rumours
that Oracle is ready to license this to MySQL AB under the same old
terms, although I haven’t found proof of that. But if you’re using
MySQL under the GPL (which you oughta be able to do with RT), then in
principle you should be able to use InnoDB tables anyway, since
InnoDB is already released under the GPL. It’s only if you are
required to use the commercial license of MySQL that you get in
trouble. (The bizarre claims of MySQL AB about the reach of the GPL
is the reason I insisted we stop using MySQL when I had the
opportunity to decide this, though. We moved our RT to PostgreSQL,
and though it was a little rocky, it’s turned out well in the most
recent release. We were already big PostgreSQL users, though.)
We use multiple terrabytes of mysql databases and have
had better resiliance from MyISAM.
How can you tell?
I’m not looking for unsubstantiated opinions about the
general technical merits of InnoDB versus MyISAM; the
subject has been beaten to death. I want to know what,
specifically, will malfunction or work suboptimally in
RT if MyISAM is chosen instead of InnoDB.
BEGIN; do work; COMMIT. It doesn’t work under MyISAM. (That this
should be news to your supervisor is more than a little alarming; but
I’ll leave the ACID flamewar to others.)
Andrew Sullivan | firstname.lastname@example.org
Information security isn’t a technological problem. It’s an economics