Hacker News Reader

Comment by Lewisham | Hacker News Reader

It depends how valuable your data is to you. For many/most companies, data is incredibly valuable, and as the company grows, it gets more valuable over time.

If you find the usability of MySQL better than Postgres, and you don't put a lot of value on your data, then choosing MySQL is fine. The author is right to point out that a lot of the complaints are really just "this doesn't have to be this way." You should really expect your database to enforce non-null, especially if it lets you specify it and doesn't warn you it's not going to do a damn thing about it.

As I mentioned in my comment above, you can fix buggy applications, but you can't fix incorrect data.

View on HN

don't put a lot of value on your data, then choosing MySQL is fine

Funny (and I use the term loosely) you should mention that.

I've just recently witnessed a situation where a BI[1] analyst was brought in around the same time I was and realized that, not only was there likely data missing, but, worse, much of the data was wrong. Said analyst has been spending a remarkable amount of effort merely convincing everyone else that the reporting logic/infrastructure wasn't broken so much as the data.

I'm not convinced MySQL itself is to blame, but it's Awfully Suspicious, considering the use of MyISAM and a kludgy, if not exotic, replication setup.

[1] Business Intelligence, aka reporting. I'm not sure how common the term is. Presumably a small company that hires someone for this role considers the data to be extremely valuable.

> You should really expect your database to enforce non-null

It does. The author of the article was wrong.

You're technically correct (the best kind of correct!) -- it's not inserting NULL. But it is inserting a value it pulled out of its ass, which I posit is actually worse. For text types it uses the empty string, for numbers it uses 0, etc. It seems to flag this as a "warning" but said warning does not appear in my terminal or in the mysqld logs, so I have no idea what it says.

Type "show warnings" to see them.

I really don't understand why people have such a problem with this (and boy oh boy am I loosing a lot of karma for this opinion).

It's not like it forces this on you. First you can turn it off, and second it only happens if you leave out the columns from the insert, don't leave out the columns and you have nothing to worry about.

I personally find it quite useful. I set column defaults as needed for real data, but when testing I let MySQL put in empty values - it saves having to type each and every column that I don't care about.

When you add "NOT NULL" to a schema, you should be thinking: "make sure the user specifies a value for this column" not "this column should be defaulted to zero." This is insane.

If you want to specify a default, well, specify a default.

Oh of course and this wass from a purely personal POV. Without trying to sound too flippant, my data can go to hell without me losing too much sleep - even if it never has in 10 or so years using MySQL. I keep decent backups and I know what behaviour to expect so personally, I'm fine with it. It's one of those 'educated' leaps of faith I take every day.

If my data integrity was so very important, I'd pass the buck to someone who knew their beans and they could find & maintain me a safe db. I'm a competent amateur (hence MySQL), not a DBA :)

Is this still true when considering silent corruption, instead of catastrophic failure? The latter is much easier to recover from...

Like I said, I haven't experienced any problems. I guess when I do then maybe I'll curse the day I foolishly told the world I was happy with mysql :)

Reply on news.ycombinator.com