But when you consider MySQL's web-centric history, its lack of transactional and foreign key support, and its relaxed attitude with regard to data integrity
2 things:
1 MySQL has had support for transactions since version 4.
2 Relaxed attitude towards data integrity Seriously?
MySQL may or may not quietly ignore transactions and foreign keys and invalid values (substituting incorrect values that happen to be valid), depending on how it's configured, and the defaults are mostly wrong (unsafe). And as far as I know there is still no option for "make my transaction fail if I try to use a table that doesn't support transactions".
Well if you don't support foreign keys in the main implementation (ISAM or whatever it's called), isn't it hard to say that you seriously care about data integrity?
The GP's point is that the default engine, and hence the one used by probably 90+% of people using MySQL doesn't support FKs and other "standard" data integrity features that you wouldn't even know to ask about, since every other major db supports them by default.
Plus if you try to create an FK on a myisam backed table it happily runs the SQL, without errors, and you think you have a working FK.
It's more like the "default default" -- you can change it so, by default, every table is created using InnoDB. IIRC, MySQL comes with an example config that demonstrates just that.
2 things:
1 MySQL has had support for transactions since version 4.
2 Relaxed attitude towards data integrity Seriously?