4 ms·

> unless someone can show me Why no. If you do not get why PostgreSQL is so much better than MySQL after reading so many people telling you otherwise, I guess

by gbog 10y ago

> unless someone can show me Why no. If you do not get why PostgreSQL is so much better than MySQL after reading so many people telling you otherwise, I guess I will not spend time on this task. There are some people prefering PHP over Python or Golang, too. Just a hint: if you did not try PostgreSQL, just maybe give it a try? And yes, MySQL kills kittens (i.e. potentially silently truncates data) at every UPDATE it receives.

marklgr 10y ago
> I guess I will not spend time on this task. Then why do you comment at all? Your post brings nothing to the discussion but appeals to popularity and shaming gp.
cyberferret 10y ago
Well, I'll give you credit for going that little bit further than the post I was responding to. At least you gave a hint as to ONE issue that MySQL can have (which, by the way, I have never come across in the millions or so UPDATES that my projects have done over the years). A link to a discussion about the problem would have been handy, but, oh well. And I actually did try PostgreSQL once or twice many years ago. If I remember correctly, it was for a project that required full text search capability, and I had no end of trouble trying to configure and optimise PostgreSQL to do it back then, and simply reverted back to MySQL which worked out of the box. Or possibly I even went to SQLite with FTS3 back then to get it to work. I, like most developers would rather be creative on my code rather than fight my tools.
conorh 10y ago
I have several websites with a reasonable number of users running on both MySQL and Postgres. On the balance I think I prefer MySQL - I find the replication in MySQL quite a lot simpler and the issues are not that big of a deal, and well known. Although I will say that both databases are fixing their faults as time goes on. For example Postgres is getting easier to configure replication and as of MySQL 5.7 the silent truncate default STRICT_TRANS_TABLES/STRICT_ALL_TABLES is fixed (although generally implementations I've used set SQL_MODE='STRICT_ALL_TABLES' by default, so it hasn't been an issue).

by gbog 10y ago

marklgr 10y ago

> I guess I will not spend time on this task. Then why do you comment at all? Your post brings nothing to the discussion but appeals to popularity and shaming gp.

cyberferret 10y ago

Well, I'll give you credit for going that little bit further than the post I was responding to. At least you gave a hint as to ONE issue that MySQL can have (which, by the way, I have never come across in the millions or so UPDATES that my projects have done over the years). A link to a discussion about the problem would have been handy, but, oh well. And I actually did try PostgreSQL once or twice many years ago. If I remember correctly, it was for a project that required full text search capability, and I had no end of trouble trying to configure and optimise PostgreSQL to do it back then, and simply reverted back to MySQL which worked out of the box. Or possibly I even went to SQLite with FTS3 back then to get it to work. I, like most developers would rather be creative on my code rather than fight my tools.

conorh 10y ago

I have several websites with a reasonable number of users running on both MySQL and Postgres. On the balance I think I prefer MySQL - I find the replication in MySQL quite a lot simpler and the issues are not that big of a deal, and well known. Although I will say that both databases are fixing their faults as time goes on. For example Postgres is getting easier to configure replication and as of MySQL 5.7 the silent truncate default STRICT_TRANS_TABLES/STRICT_ALL_TABLES is fixed (although generally implementations I've used set SQL_MODE='STRICT_ALL_TABLES' by default, so it hasn't been an issue).