7 ms·

Only the auto-updating timestamp thing has really got in my way in the past. Much as I liked Postgres when I used it, I have such easy access to MySQL and I so

Only the auto-updating timestamp thing has really got in my way in the past. Much as I liked Postgres when I used it, I have such easy access to MySQL and I so rarely encounter any problems that I kinda ignore the toy jibes. Maybe I'm not pushing it enough but if that's the case, why should I jump through hoops to set up something I won't be making good use of?

Lewisham 16y ago
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.
- kingofspain 16y ago
  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 :)
  - JoachimSchipper 16y ago
    Is this still true when considering silent corruption, instead of catastrophic failure? The latter is much easier to recover from...
    - kingofspain 16y ago
      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 :)
- mmt 16y ago
  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.
- ars 16y ago
  > You should really expect your database to enforce non-null It does. The author of the article was wrong.
  - gxti 16y ago
    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.
    - ars 16y ago
      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.
      - gfodor 16y ago
        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.

Lewisham 16y ago

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.

kingofspain 16y ago
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 :)
- JoachimSchipper 16y ago
  Is this still true when considering silent corruption, instead of catastrophic failure? The latter is much easier to recover from...
  - kingofspain 16y ago
    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 :)
mmt 16y ago
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.
ars 16y ago
> You should really expect your database to enforce non-null It does. The author of the article was wrong.
- gxti 16y ago
  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.
  - ars 16y ago
    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.
    - gfodor 16y ago
      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.