41–48 of 48 posts
Horrible article. The same guys that pimped NoSQL three years ago now just hype something else. I have nothing against Postgres (I use it myself) but inflammatory articles like this are of use to no one other than their authors.
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.
> That's an application-specific function that shouldn't be bloating a database engine. 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.
Wonderful, this is also posted on an '.xxx' domain so it is categorised as adult material by my company's proxy. Gee thanks. From the comments here though I'm not missing anything.
Earlier quoted context omitted.
Amazon RDS support.
RDS is awful. The interface is shitty and buggy, offers graphs that you can't do anything with, the backups cause our system to fail every night, EBS backing has serious spiking problems, you can't access the replicas and it runs a shitty custom fork of MySQL
For what it's worth, I've used Postgres in production systems with great success.
I was actually discussing this today: > Schema-less data, array columns, queueing, full-text searching, geo-spatial indexing, it's insane what Postgres can do. Ok for arrays and geo. Maybe for integrated search. But where is the line between bloat and useful features? Do they really need queueing in the database itself, or schema-less parts? Each part is something that needs maintenance, possible bugfixes and caring…
And where will it stop? Will it have a built in email client next? While it may seem nice and convenient to have all these different features in one nice package, I'm struggling to see what that's such a good idea in the long run. The thing with the separation of concerns means you use software that does one thing and does it well . Maybe this comes with a greater maintenance cost, I don't know, but I think I'd feel…
All RDBMS engines have a variety of features that are not necessary in all deployments.
Earlier quoted context omitted.
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…
Last time I checked, MySQL isn't governed by fate. What happened three years ago (or a year ago etc) has absolutely nothing to do with what the MySQL team does tomorrow in regards to improving the software. 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.
Earlier quoted context omitted.
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.
except it doesn't, it's an optional extension
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.
> That's an application-specific function that shouldn't be bloating a database engine. 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.