31–40 of 48 posts
"I seriously want someone to tell me just ONE feature that MySQL has over Postgres. I ask everybody this question, and I haven't heard a single thing. " Built-in two-way (aka master/master) replication.
Postgres has had solid replication since 8.4
The article's arguments aren't that convincing. Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. If anything, the grocery list of crap mentioned by this article makes me DOUBT Postgres's focus on being an efficient database. The other problem is that every host offers MySQL. Not so with Postgres.
> Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. You could just as well say that multi-text-encoding sort/group collation, compound keys, or, for that matter, indexes on anything other than primary keys, are "application-specific function[s] that shouldn't be bloating a database engine"--and then go back to using BerkeleyDB. The point of relational databases…
Should there be special functions for querying the characteristics of JPEGs stored as BLOBs? How about PNGs?
Where does this end? Just because a couple of float values happen to represent latitude and longitude doesn't mean the DB engine should integrate geospatial logic.
Nothing like exaggeration in headlines taken to the extreme. MySQL is fine. Even if you accepted the premise that Postgres had become the better piece of software, MySQL has a massive installed user base and every opportunity to catch up and improve.
It took what, five years to fix the glaring design flaw where you couldn't use NOW() as the default in a datetime field. Seriously, this was just fixed a few weeks ago after years of outrage over it, and it was fixed by an outsider: http://bugs.mysql.com/bug.php?id=27645 Now we all get to wait for our hosts to update their MySQL installation, once the fix makes it into a release. How many more years will that be? If…
If things actually worked that way, Windows 7 would have been worse than Vista, and the quality of iTunes today would ensure Apple could not compete for the future of the music market.
I wonder how posts like this make it to the front page. This is clearly a opinionated and poorly researched article that gives no evidence for any of its claims, except that a few features this user wants are included in PostgreSQL. There is still plenty of space PostgreSQL has to make up before it is better then MySQL in every way. The knowledge gap alone is enough to keep MySQL around.
where does postgres need to catch up? and what knowledge gap?
"I seriously want someone to tell me just ONE feature that MySQL has over Postgres. I ask everybody this question, and I haven't heard a single thing. " Built-in two-way (aka master/master) replication.
Amazon RDS support.
Earlier quoted context omitted.
> Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. You could just as well say that multi-text-encoding sort/group collation, compound keys, or, for that matter, indexes on anything other than primary keys, are "application-specific function[s] that shouldn't be bloating a database engine"--and then go back to using BerkeleyDB. The point of relational databases…
OK, then why shouldn't there be a special function to assess the cost of the beer in any specified currency at the time of the query? Should there be special functions for querying the characteristics of JPEGs stored as BLOBs? How about PNGs? Where does this end? Just because a couple of float values happen to represent latitude and longitude doesn't mean the DB engine should integrate geospatial logic.
"I seriously want someone to tell me just ONE feature that MySQL has over Postgres. I ask everybody this question, and I haven't heard a single thing. " Built-in two-way (aka master/master) replication.
Postgres has had solid replication since 8.4
MySQL has supported this since at least version 3.2.3, released in January 2001.
MySQL supports
• Single master to one slave • Single master to multiple slaves • Single master to one slave to one or more slaves • Circular replication (A to B to C and back to A) • Master to master
Postgres supports
• Single master to one slave • Single master to multiple slaves
(lists from http://www.theserverside.com/feature/Comparing-MySQL-and-Pos...)
Worse is better. MySQL's terribleness is its feature; it means you stop and think before putting business logic in the database, writing a stored procedure, or joining on five tables. While it's a worse database, the /systems/ I've seen built on MySQL are all better than those built on "real" databases.
While it's a worse database, the /systems/ I've seen built on MySQL are all better than those built on "real" databases. This could be a symptom of which businesses choose which databases. Large established businesses are probably going to prefer the commercially supported database, and are probably also going to have the resources to build impressive systems.
The article's arguments aren't that convincing. Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. If anything, the grocery list of crap mentioned by this article makes me DOUBT Postgres's focus on being an efficient database. The other problem is that every host offers MySQL. Not so with Postgres.
GIS most certainly belongs in the database. You don't want to load gigabytes of geo data as points in memory and build and filter geometries in whatever your application is, anymore than you want to load any non-trivial dataset in-memory and do your filtering in your application language.
Earlier quoted context omitted.
> Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. You could just as well say that multi-text-encoding sort/group collation, compound keys, or, for that matter, indexes on anything other than primary keys, are "application-specific function[s] that shouldn't be bloating a database engine"--and then go back to using BerkeleyDB. The point of relational databases…
OK, then why shouldn't there be a special function to assess the cost of the beer in any specified currency at the time of the query? Should there be special functions for querying the characteristics of JPEGs stored as BLOBs? How about PNGs? Where does this end? Just because a couple of float values happen to represent latitude and longitude doesn't mean the DB engine should integrate geospatial logic.
With Erlang QLCs :)