At the risk of jumping into on on-going discussion at a late point, I'd like to make some (hopefully useful to you) comments:
- InnoDB should work with ALL queries that work with MyISAM. It is a different engine, not SQL syntax. The MySQL application determines the syntax.
- Using MyISAM has its advantages, as does using InnoDB. It depends what you value more (see below).
- In it not necessary to use ORM with InnoDB. Regular SQL works just as well.
- It is possible to have a mix of engines, where specific tables use specific engines. Converting a table from one engine to another is a matter of a single statement (ALTER TABLE table_name ENGINE = engine_name).
Having worked with various databases (Sybase, Oracle, MySQL, MSSQL, Access) in applications ranging from simple spreadsheet to a fully distributed global app, the benefit of consistency and resiliency far outweigh the (usually small) performance hit.
Main differences between the two engines:
- No Foreign keys and cascading deletes and updates
- No rollback abilities
- No transactional integrity (ACID compliance)
- No full text indexing
- Cannot be compressed for fast, read-only
While most stores involve reading the database, usually the information required is already cached in the database memory. This makes the underlying engine irrelevant. Even when requiring a physical read of data, most stores do not have the size (millions of items) and customer hits (thousands of hits a second) that will make any performance differences noticeable to the user.
However, the importance of ensuring that updates to stock, captures of orders, and other writes to the database are consistent and atomic, is of paramount importance. The worst thing that can happen to a store is that a customer thinks he/she placed an order, but the order was not recorded in the database. There are ways to ensure this does not happen within the application, but then the application code begins to compensate for the database's deficiency. It is best to use the database with its focus on this functionality and capture of all such cases.
Performance aside, the availability of foreign keys helps ensure that the design the developer had in mind is maintained even if the code has bugs and tries to create improper data relationships.
All these little things make InnoDB a better choice than MyISM if you write data of any significance.
Just my 2 cents...