every time I read a PostgreSql vs MySQL post the only thing I can seem to take away from it is that DBA's really seem to hate the fact that MySQL has made them obsolete and really want you to think you should switch to a platform where they are necessary.
PostgreSQL vs MySQL: an apples to oranges comparison
11–20 of 71 posts
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#12Really well thought out article.
The single app vs. multiple apps distinction is a good frame for constructive discussion.
Not so much because Postgres is better or vice versa but because in these days of agile and YAGNI development* there's a real problem with some developers not thinking further than the next iteration.
I like that development shouldn't be weighed down by 'what if we'll need X someday maybe' but it should have at least a rough roadmap - the terminology i use next is irrelevant but I'm getting at the idea of having macro, micro and miso level goals defined - in the future we'll deliver architecture concern Y, so let's not box our implementation into an incompatible state.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#13I've never been able to completely dismiss MySQL since it obviously works for so many users, but I also haven't found it very useful in my work. I started with PostgreSQL in the '90s and every time I tried to use MySQL, I found myself asking either "why did it do that"? or "why would I want that"?
The article describes two databases that are very different conceptually, and I think they're mirrored by users that conceptually think about data in different ways. So if one or the other works well for you, go for it.
I should note that I have successfully deployed applications on both platforms ... once I started doing most of my database interactions through an ORM, the differences didn't really matter any more.
Vive la difference!
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#14Are there any books out there that describe how to efficiently use PostgreSQL's object-relation techniques?
I am actually thinking of writing one. My blog (yes I am the author of the article, http://ledgersmbdev.blogspot.com) is basically running a fairly large series on these features.
The big thing to realize is that there are two aspects here: development efficiency and complexity cost on one hand, and db performance on the other. A lot of the O/R capabilities really do have a significant complexity cost and it is easy to code solutions that don't work very well performance-wise or otherwise.
In a bit over a week, I will have general recommendations out on the blog entry. As a brief preview:
1: table methods are generally good
2: nested storage is generally bad
3: table inheritance is frequently used for the wrong things. It is a very powerful technique if you think in terms of composition, but not so great if you think in terms of inheritance.
4: avoid to the extent you can putting tuples in columns. Postgres gets really weird in these cases.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#15every time I read a PostgreSql vs MySQL post the only thing I can seem to take away from it is that DBA's really seem to hate the fact that MySQL has made them obsolete and really want you to think you should switch to a platform where they are necessary.
The article wasn't written by a DBA. Reading isn't one of your strong points is it? Neither, if you think MySQL makes DBAs obsolete, is thinking.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#16If you cannot compare PostgreSQL to MySQL then what databases can be compared?
the point of this article is that Postgres is not just a database
You have to define "just a database" (I am the author btw).
PostgreSQL is a very different kind of database than MySQL is. MySQL is closer to a persistence layer for an application with an ability to plug into other reporting tools. PostgreSQL is a data modelling platform.
Both are "just databases" or not depending on how you want to define "database." I would say it is clear that PostgreSQL is not just an RDBMS but that's the point of other articles on the blog, not this one.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#17every time I read a PostgreSql vs MySQL post the only thing I can seem to take away from it is that DBA's really seem to hate the fact that MySQL has made them obsolete and really want you to think you should switch to a platform where they are necessary.
I've either inherited or hired a mysql dba at my last four jobs. In fact I'd say its a close call as a young/small internet company grows whether they should hire their first dba before they hire their first sysadmin, as you're probably going to get more immediate wins out of the dba.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#18Quick summary, assuming you know what MVC stands for:
Mysql - Model is in your code. PostgreSQL - Model is at least partially in your database.
There is a HUGE mistake in the article in the assumption that WRT the model design, that the database always knows best. Its possible to come up with weird situations where you just want the DB to store stuff and not nanny you. Consider a database of actual, real world, gravestone inscriptions. If someone's gravestone stone has "1890-02-30" inscribed on it, I know thats wrong but I don't care, I need to store it exactly as is for historical purposes, I don't want a DB crash or need to recompile postgres to accept it, I don't want to force the users to falsify gravesite records, I don't want to have to store as a CHAR or VARCHAR and have to write my own date handling routines in my app... The correct way to handle data modeling/integrity is to allow the app designer to decide how flexible he wants to be WRT reality, and let him decide exactly how to shoot himself in his foot.
On a bigger scale, if I made a database table and related CRUD app to store philosophical positions, if I wanted an AI to only accept "truth" then I'd put the AI in my app, I would not want the DB model and the app model to have to fight over Marx being right or wrong before the data could be stored. What if filesystems needed to verify "truth" before allowing a file to be saved? Weird.
Is it persistent storage or is it a turing complete theorem prover and why most both be in the same executable? Note I'm not claiming a "middleware" of a model is a bad idea, in fact its a great idea, it just doesn't belong in the persistant DB store anymore than it belongs in the filesystem layer.
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#19Quick summary, assuming you know what MVC stands for: Mysql - Model is in your code. PostgreSQL - Model is at least partially in your database. There is a HUGE mistake in the article in the assumption that WRT the model design, that the database always knows best. Its possible to come up with weird situations where you just want the DB to store stuff and not nanny you. Consider a database of actual, real world, grave…
How is MySQL going to store "1890-02-30" as a date? What internal format does it use to allow storing a date like that?
Re: PostgreSQL vs MySQL: an apples to oranges comparison
#20every time I read a PostgreSql vs MySQL post the only thing I can seem to take away from it is that DBA's really seem to hate the fact that MySQL has made them obsolete and really want you to think you should switch to a platform where they are necessary.
Hmmm.... if you think MySQL has made DBA's obsolete, then you haven't had much experience with it.