Rewriting "exists (subselect)" into joins works, but you lose one of
the benefits of the original construct - the query can stop execution
the moment the "exists" is satisfied (regardless of whether or not
there's a "not" in front). The savings using "exists (suhselect)" can
be very significant.
Just ignore what they say about foreign keys, they don't know what
they're talking about. I thought it was some sort of warped April
Fool's joke or a vandal's hack on their website when I first read it.
As far as answering the actual question raised by Anthony, though -
InnoDB looks like it could be a very good back end. My guess is that
it will require some seasoning in the field before it lives up to its
potential or can really be considered reliable. This isn't a knock on
Innobase, it's just reality - RDBMS engines are hard to get right and
concurrency problems are subtle and frequently only crop up
occasionally and are very difficult to reproduce.
I've not looked at their website in a couple of months, but in some
regards its still incomplete. There's an 8KB limit on either column
or row length, for instance (sound familiar, ye olde Postgres
veterans?). They plan to work their way past various restrictions but
expect it to take some time.
The InnoDB back end is an Oracle-style storage manager, with row-level
locking, following an overwriting paradigm with rollbacks etc done
from redo logs.
One of the reasons I think it might be good is that originally it had no
connection with MySQL. In fact, I think they intended to write their
own full-blown RDBMS at one point. Whatever the specifics, it's been
glued to the MySQL front end. The folks doing InnoDB obviously have a
somewhat more reasoned and mature notion of what an RDBMS should be
than Monty and the rest of the MySQL crowd.
They firmly believe in the importance of ACIDity, for instance, and
probably laugh as heartily as we do at some of the stupid things the
MySQL folk
have said in the past.
There's still the little problem of the weakness of the SQL dialect
supported by MySQL, as others have pointed out.
