> If you have 20 data tables with a lot of relationships among them, do > you think that is reason enough to choose InnoDB -- with its support for > transactions and foreign keys -- over MyIsam?
If you need transactions and foreign keys, then yes. > I'm working on an app and taking great pains to preserve integrity at > the application level and coming to realize that it's even harder than I Don't - it's not really possible, and if you truly need that type of thing, it has to be done in the database anyway. > thought. Say you have a form with a dropdown populated by some data from > table x. I validate the input to make sure the user isn't maliciously > choosing a value of their own choosing rather than my select menu. Fine, > but in the meantime some other user came long and (legitimately) deleted > from table x the row whose id the first user is submitting. So after > validating, if using MyIsam, I would have to lock tables and a run > sanity-check SELECT query to make sure the row in x still exists. This > is gonna be happening rather a lot. I think those extra queries will > offset some of the performance advantage of MyIsam over InnoDb. Yes, it gets ridiculous. And in some cases, like these, InnoDB will be faster anyway. > Also, in my case, it's unlikely that I will ever see much of a server > load. A few people will be admins doing reads and writes, a few more > people -- like maybe 100 or 200 -- might be mostly reading > intermittently over the course of a typical day. Go for InnoDB if you need that type of functionality - the performance won't make a difference with that type of traffic. H _______________________________________________ New York PHP Community MySQL SIG http://lists.nyphp.org/mailman/listinfo/mysql NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
