Hacker News Reader

Comment by blhack | Hacker News Reader

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?

View on HN

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?

MySQL DOES have support for foreign keys.

create table foo (blah, blah, blah) engine = innodb

Sorry, I'm not trying to start an argument. That sentence just struck me as a bit inflammatory.

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.

I'd bet 90%+ of companies using MySQL for anything serious are using InnoDB.

The article is vague on when MySQL was dissed, but the closer you get to 2002, the more common MySQL 4 was.

Reply on news.ycombinator.com