https://panel.dreamhost.com/index.cgi?tree=home.sugg
"Huns, I have DreamHost, but why should I click that link and vote for InnoDB?"
If you are interfacing systems developed in SL with systems developed at DreamHost, you are probably using a MySQL database at DH, which supports only MyISAM tables. This is okay for a lot of applications, but if you have to have safe transactions - i.e. you are writing software that has something to do with money, such as order entry and fulfillment - you are vulnerable to data loss or corruption should something fail in the middle of a transaction. To give you an example, if you are transferring money from user A to user B, you have to debit A's account and credit B's account. Those two things need to either both happen, or both fail, in order for your system to remain consistent. If you debit A, but then there is a power failure or someone kicks out a network cable or takes mysqld down for maintenance or something like that before you credit B, one of your customers is going to be missing money and the other is going to wonder where their money is. You may think this is a rare occurrence, but when money/goods/etc. are involved, you owe it to your customers to take every step to protect against this kind of failure.
With InnoDB, you can do something like this:
BEGIN
UPDATE Accounts SET Balance = Balance - 50 WHERE User='Joe Blow';
UPDATE Accounts SET Balance = Balance + 50 WHERE User='Phil Suckalewski';
At this point, if you enter COMMIT, both transactions are done, and the results are committed simultaneously. If something breaks in the middle of that, the database remains at its former state, before the BEGIN statement was entered.
If you enter ROLLBACK instead of COMMIT, both transactions are undone. This is also done if your application terminates its MySQL connection without sending COMMIT - so if the server your app is on should die in the middle of all this, the database goes back to its previous state.
Is it possible to do something like this with MyISAM tables? Yes, but you have to implement the logic for it inside your application. This adds complexity and development time to your project. You have to figure out some kind of journalling mechanism that can recover from failure at ANY point (which can be done but isn't a simple task), and then you have to run periodic consistency checks. You also have to read-lock the entire table during the transactions, which will cause any other processes reading it to stall, even if they are not looking at the same account! InnoDB supports row-level locking if you need it (and if you are smart, you will read-lock your rows before you update them, in order to protect yourself from race condition attacks.)
InnoDB also supports foreign key constraints (no CASCADE though), which you may miss if you are used to developing on more full-featured databases.
TIA