Friday, May 02. 2008What can PostgreSQL learn from MySQLPrinter FriendlyRecommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
Comments
Display comments as
(Linear | Threaded)
Regarding "Zack Urlocker of Sun has espoused, the upcoming MySQL 5.1 will have no bugs so perhaps this along with other bug complaints is a moot point."
Huh? Software with no bugs? Sounds like a marketing gesture to me. Where did you get this quote from? -jay
Its in the eWeek Ferrari of Databases article we listed above. The exact phrase used was "This version now has zero bugs," Urlocker told eWEEK. I think what he meant was all bugs in MySQL bug tracker have been corrected.
> PostgreSQL people look like a gang of geeks and Martin Mickos looks polished
I'm curious just exactly which "PostgreSQL people" you're referring to here. The vast majority of the people who travel and speak keep both their hair and their words short and tidy. There are two people I can think of offhand who wear ponytails, and neither of them otherwise fits any "geek" stereotype.
Hi David,
I tend to agree with you that I think the pony-tail/geek argument doesn't hold too much water. I mean, Jonathan Schwartz, CEO of Sun, has a ponytail and bridges the professional and the geek quite gracefully. :) However, I *do* think that the authors of this article are correct in that there is certainly an attitudinal difference between MySQL "advocates" and PG "advocates". The former, in my experience, tend to me more moderate and less dogmatic about theoretical things than their PG counterparts. The dogmatism and ideology of some PG advocates, especially in the arena of licensing (BSD vs GPL) and the arena of "pure relational DBMS" arguments have been a turn-off to elements of the broader technology field that are not DBAs by trade. To put it in a one-liner, you will rarely find a MySQL user/advvocate say that "PG is crap". Instead, often they will say "PG is great, but different, and more complex". But the opposite, im my experience, is not true. I often run across blog posts and PG advocates that generalize "MySQL is crap. Use PG, it's a *real* database". This attitude is a turn-off to a large segment of people. Just my two cents. Cheers, Jay
I would have to agree with Jay's thought about attitude. While it's not true for everyone in the pg community it is true for many. It's not even *just* against mysql. It's against every other database. It seems that if it's not done the pg way, it's not done the right way.
LewisC
Okay I admit, the ponytail pick was a bit unfair. I guess I was thinking of the comic store owner guy in Simpsons whenever I hear someone in PostgreSQL groups make a snide remark about MySQL and other things. I admit I am not immune to this fault so part of it is a pick at me too. It just irritates me immensely when I see the reflection of my worst inner faults in others. :)
- e.g. "ah you were using that pedestrian database to do real work? No wonder you have problems." "STOP TOP POSTING!" You have to admit that comparing being terse and to the point vs. being mean is like comparing apples and oranges. You can be very mean and to the point at the same time.
This post reads a bit like a joke -- it's hard to take it seriously. Maybe that was done on purpose?
Anyhow, I'd appreciate it if you could elaborate on "...PostgreSQL has caught up there and is beginning to see the fruits of that labor." -- what kinds of fruitds of that labour is PG seeing? Could you describe that a bit more, please? Thank you.
This is just from personal experience. We meant that before we'd have clients where PostgreSQL was a better option for them than say MySQL or SQL Server and it was a really really hard-sell to pitch PostgreSQL. For lots of things it really doesn't matter if you run MySQL or PostgreSQL or SQL Server.
Now we are seeing clients (even those running on Windows) that are already sold on PostgreSQL before they come to us.
MySQL is popular for the same reason Visual Basic is popular, it is simple to get started with and you see instant results.
Take a fresh download of Postgres, the steps to get TCP/IP configured are not straight forward or obviously documented - MySQL just works. Some of the non-standard features that make MySQL so poor in the eyes of a professional, actually help soften the learning curve of the database for those with little experience who aren't used to thinking like a DBA. As you get started on your first MySQL based project and start creating a schema, things like auto_increment are easy to get your head around. And just as with many Microsoft extensions to standards, those features end up being a barrier to entry with other databases as you progress, keeping people hooked on MySQL and finding ways to make it work for them, rather than having to discard everything they've learnt to date. Postgres documentation for those who are already literate in DB speak is very comprehensive and covers all the features. However there are two distinct gaps in the documentation: 1. Beginners guides, written in plain English, that explain the basic concepts and technical terms that people are going to come across, as well as taking them step by step through their first example project. This guide should really be database agnostic, but provide examples for Postgres. 2. A concept migration guide - there are lists of features that Postgres has that MySQL doesn't, and the like, but I have not found a guide that explains in simple terms what each of those features is, how to use them, why you should use them, and how they all fit together. Finding out the syntax for a particular statement is easy, but finding out how and why you should be using that facility is not covered. I think that both these issues help reinforce the outsiders view that PG people tend to have an elitist attitude to non-PG people. I write this as a recent convert, having finally had enough of MySQLs limitations with an enterprise class project, that had started out small and grown beyond the DB's capabilities. I always looked at the feature set in PG with envy, but until recently I found the DB just too different for me to want to invest in making the switch.
Having no experience with PostgreSQL I will not engage in technical details but rather speak of my journey with MySQL. In the late 90's, my former boss decided to switch our SW to true SQL server. After many a discussion, choice fell on MySQL. At first, we were amazed with speed and ease of use. Later on, when problems surfaced, I was always able to get Monty or Sinisa on the phone and ask for advice. This was a great asset to us! Following on this, MySQL got from us one of the first Windows GUI client and numerous replies on windows mailing list once it was established. My point being you need quality response from community and to get that you need to invest a lot! Take a Jay Pipes for example (btw. Hi Jay!), MySQL community team consists of great professionals lead by one of the most important persons in MySQL. No compromise, community get's the best.
This brings me to, along with Chris's comment "1. Beginners guides, written in plain English", another point I wish to make. Although above seems unrelated, it is! What Marten brought to MySQL, besides looking sharp ;-), was enough money to be spent on community, support & docs team. It is my opinion that all three teams are of top quality in business. And only support makes money. So, it doesn't seem right to attack MySQL over commercializing part of it's offers as most of the money goes back to where it should, to community. To the authors, minority of one doesn't mean you're crazy! Although Nietzsche was well aware how hard that might be. Do not antagonize people for being fond of "anchoring", it is our nature. I have never met a vegetarian that didn't try to "convert" my eating habits ;-). Finally, I'm looking forward to checking into PostgreSQL deeper, now that we're all part of SUN.
It's all about the name.
Well, no, it's not all about the name. But I wish it would change. It's not that it's really bad (not compared to the gimp anyway), it's just that it stumbles off the tongue, and it's not very memorable. "Howdyou say that now? Post Rest QL?" Quite honestly I've recommended the use of PostgreSQL quite a few times when it was the appropriate tool but the name always seemed to be a bit of a stumbling block. When you're trying to pitch to a non-techy crowd, the name is more important than it ought to be. It started as Ingres. Why couldn't it have been called Egress and saved me all this hassle? :-)
I agree too. Even Oak as stupid as it is slides off the tongue more easily. Saying PostgreSQL just doesn't make you sound like a smooth talker in meetings.
I would like to raise one MySQL feature to the list, working integrated replication. PostgreSQL replication is a joke compared to MySQL one. Not to even get started with non-working PgCluster compared to very proven MySQL Cluster. Building high available, scalable systems is quite hard with Postgres, and that is a big problem if one wants to use Postgres for commercial applications.
Yes it's possible, I have setup DRBD + Slony replication for my company, but I used to maintain large MySQL replication and damn it was easy and better working.
Thanks for the link. I'm happy to see others using S9Y. :)
I'm actually more a fan of PostgreSQL than MySQL. In fact, the only thing I like about MySQL is the pluggable storage engine option. If there's a way to do something similar with PostgreSQL I'd love to learn about it. One comment concerning the lack of polished geeks promoting PG: Martin Mickos fits in with the business types because he runs a business. And that's really the key - the simple fact that there's a business behind MySQL makes it immensely more acceptable in the corporate world. There's a contract to sign and an entity to sue (if necessary), and that makes it palettable. Not so with PostgreSQL, at least not as far as I know. And until or unless that changes, PostgreSQL will never be adopted, officially or unofficially, as much as MySQL.
You are welcome Tom. I remember someone mentioning that way back when (e.g. maybe in the 6+ era) PostgreSQL had a pluggable storage engine, but the feature was discarded because it was too much trouble to maintain.
As far as contracts to sign and entity's to sue, I always thought most organizations are over that or at lest they are into suing consultants rather than software vendors. I can't really imagine suing Oracle for anything and their contracts seem more like customer chains. Still I think a lot of people read a lot into a suit and just because we are open source hackers doesn't mean we can't look good too :). I never think of an entity to sue behind apache, but that is largely an accepted webserver by corporate types although I never paid much attention to the Apache model or the face of apache so maybe there is something behind that.
And we have to add that MySQL is vastly easier to program than PostgreSQL. Just try to write a procedure that returns a result set in PostgreSQL.
The weird distinction between PostgreSQL and PlSQL means programming PostgreSQL requires more skills. For most applications MySQL is good enough. And easier to program. Note that I myself prefer PostgreSQL, but would hardly ever recommend it to a customer.
Berend,
I would agree that for most applications MySQL is good enough, but not necessarily easier to program. I too have recommended it over PostgreSQL for other reasons - e.g. it was an application that they needed well supported by many ISPs, they already had a MySQL server and were comfortable with it and they weren't doing anything complicated. But NEVER because it was easier to program. The easier to program is I think more a perception than reality. If you are doing something trivial it will be trivial in either. Just because people tend to do simpler things in MySQL doesn't make it easier to program. If you look at even Monty's criticisms of MySQL http://www.scribd.com/doc/2575733/The-future-of-MySQL-The-Project on slide 12. You can not use set returning stored procs of MySQL in the from clause which I find to be a huge disadvantage for most of the applications we write and makes many SQL Server to MySQL job ports painful. For simple set returning functions - nothing is easier than a PostgreSQL SQL set returning function. The MySQL PL is NOT easier. I have had really bad experiences in MySQL where I wrote a marginally complicated View for one 5..release. something version and in a minor point newer release the view just didn't work at all. The same view works perfectly in SQL Server and PostgreSQL with no change. For MySQL prior to 5 - I even refused to work on many such jobs or charged a 20% premium because I can't imagine living without views for a marginally complex project.
I think a big part of the issue is support. I can google MySQL and find more sites and problem resoultions and work arounds than I can count. Attempting to do the same thing with PostgreSQL, a developer and DBA finds themselves with limited resources. Even looking for books locally, there is amuch smaller selection and therefore less support.
|
Entry's LinksQuicksearchCalendar
Categories
Blog Administration |
This is the 96th edition of the weekly review of database blogs, Log Buffer...
Tracked: May 09, 12:57
First this is a windows only package, but nevertheless sweet. In our article What can PostgreSQL learn from MySQL? we complained about the fact that there is nothing like Server2GO pre-packaged with PostgreSQL. Low and behold comes this thing called
Tracked: Jun 18, 08:49