4 ms·

> inability to be a good database Judging from shitloads of successful companies and projects running MySQL in production I'd argue the inability here is with

> inability to be a good database Judging from shitloads of successful companies and projects running MySQL in production I'd argue the inability here is with the developer. Can you substantiate your claim or is your dissatisfaction just rooted in your inability to run a MySQL server?

vertex-four 9y ago
Or... perhaps those companies are just able to paper over MySQL's deficiencies at a lower cost than switching to Postgres with a product that's already in production. MySQL is very, very well-documented to be a poor database engine that does some terrible things with your data without warning. There's several good alternatives - Postgres being free, MS SQL Server being a reasonable paid-for option, and there's Oracle and IBM's database systems at the high end. One of the only reasons to develop a new project for MySQL (assuming your developers are at all capable of writing queries for Postgres, which is hopefully the case) is that you know your deployment environment is going to have MySQL. Which is probably the case here - LAMP is still a popular stack among PHP developers, so there's a very good chance that anyone wanting to deploy Ghost already has a MySQL server.
neverminder 9y ago
Run this query on both MySQL and Postgresql, should explain it all: SELECT 0 = 'banana'
zimpenfish 9y ago
Having run MySQL servers and suffered the problems for many years before I finally gave up, I don't think it's my inability that's the issue here. As a counterpoint, many successful companies run PHP in production but I don't think anyone would claim that means it's a good language. (One example of where MySQL lack{s,ed}: Postgres with a functional index on a field handled the exact same query on the exact same data a couple of orders of magnitude faster than MySQL on the exact same box.)
- y4mi 9y ago
  eh, quite a few people say that the later php versions are wonderful to work with. not talking from experience though, never used it for anything remotely serious.
hobs 9y ago
MySQL has a historical record of fast then correct. Much of this has been fixed over the years, but scars still shine on the skin of DBAs and sysadmins in many many places. Also, big appeal to authority here, many successful companies do silly things with databases.

vertex-four 9y ago

Or... perhaps those companies are just able to paper over MySQL's deficiencies at a lower cost than switching to Postgres with a product that's already in production. MySQL is very, very well-documented to be a poor database engine that does some terrible things with your data without warning. There's several good alternatives - Postgres being free, MS SQL Server being a reasonable paid-for option, and there's Oracle and IBM's database systems at the high end. One of the only reasons to develop a new project for MySQL (assuming your developers are at all capable of writing queries for Postgres, which is hopefully the case) is that you know your deployment environment is going to have MySQL. Which is probably the case here - LAMP is still a popular stack among PHP developers, so there's a very good chance that anyone wanting to deploy Ghost already has a MySQL server.

neverminder 9y ago

Run this query on both MySQL and Postgresql, should explain it all: SELECT 0 = 'banana'

zimpenfish 9y ago

Having run MySQL servers and suffered the problems for many years before I finally gave up, I don't think it's my inability that's the issue here. As a counterpoint, many successful companies run PHP in production but I don't think anyone would claim that means it's a good language. (One example of where MySQL lack{s,ed}: Postgres with a functional index on a field handled the exact same query on the exact same data a couple of orders of magnitude faster than MySQL on the exact same box.)

y4mi 9y ago
eh, quite a few people say that the later php versions are wonderful to work with. not talking from experience though, never used it for anything remotely serious.

hobs 9y ago

MySQL has a historical record of fast then correct. Much of this has been fixed over the years, but scars still shine on the skin of DBAs and sysadmins in many many places. Also, big appeal to authority here, many successful companies do silly things with databases.