Hacker News new | ask | show | jobs
by nailk 3358 days ago
> MySQL's traditional "fast" table type doesn't support transactions

InnoDB is the traditional table type now. Myisam was forgotten long time ago.

> we had to set up our own custom collation to get, for example, "e" and "é" to be considered distinct characters

You could just use "varchar CHARACTER SET utf8 COLLATE utf8_bin"

> MySQL infamously accepted almost any kind of garbage values regardless of declared column type

There is a setting that allows strict checking.

> I cannot at this point imagine using MySQL for any kind of serious project.

It is used by many for serious projects.

2 comments

In regards to charset and strict checking, these are settings which should be defaulted. I think the problem is that people run into these issues then have to seek solutions, which shouldn't be issues to begin with. I don't know why they aren't now defaults.
Pretty much. "By default we mangle and throw away your data, but there's a configuration setting to change that and make it actually store what you wanted to store" is not a useful way to do things.
Strict has been the default since MySQL 5.7. The default character set switches to utf8mb4 in MySQL 8.0.
That's great to hear.
I'm reminded of https://developers.slashdot.org/comments.pl?sid=204433&cid=1... as I read this exchange.

I found the above link in another HN thread some time ago. When I showed it to some PHP devs recently (I unfortunately don't remember exactly who I talked about it to) I was promptly told PHP does not do what is described in the above link (from 2006) and is generally smarter nowadays.

It's sad that languages and runtimes take so long to fix their core insanities (if ever), and it's also sad when systems are built without front-and-center regard to design correctness from the start. But on the flip side, the only people capable of envisioning good designs of this level of scale are often worn out shells of their former selves at the "you'd have to pay me 7 figures" stage... and of course you have to make sure you pick people who aren't completely out of touch with the latest developments in $category science...

> You could just use "varchar CHARACTER SET utf8 COLLATE utf8_bin"

You don't get UTF-8 if you do that though, do you? That was MySQL's first attempt at UTF-8 support. You have to tell MySQL to use utf8mb to get complete support for UTF-8.