Not a good article at all. It makes MyISAM sound good which just isn't the case.<p>MyISAM is good for read-only tables. It has very fast reads. Once you start getting writes, it crumbles. Since most web applications today have a decent amount of writes, MyISAM isn't that good.<p>So what is MyISAM good for? Well, let's say that you have a table of post codes. Maybe you want to add new ones every month, but for general purposes, it's read-only. You'll get MyISAM's speed for reads and writes won't matter.<p>On the other hand, say you're making a site like HN. In that case, you constantly have writes (votes, submissions, comments) and locking the table isn't an option as it would just crumble.<p>The article says that MyISAM is good if your application "has to be fast". That isn't true. Most applications would be faster with InnoDB. This article takes a completely inaccurate approach to databases. So, they'll be lots of people who read this and think, "faster is better, therefore I'll use MyISAM," when such a choice will give them lots of speed problems as users start using their app.
Very basic explanation of the pros and cons. It assumes a total beginner audience.<p>I think that the lack of foreign key constraints and transaction support needs to be emphasized more, especially considering who the audience is.