Re: [HACKERS] What can we learn from MySQL? - Mailing list pgsql-advocacy
From | Tim Conrad |
---|---|
Subject | Re: [HACKERS] What can we learn from MySQL? |
Date | |
Msg-id | 20040427152753.GA34713@external.timconrad.org Whole thread Raw |
In response to | Re: [HACKERS] What can we learn from MySQL? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] What can we learn from MySQL?
Re: [HACKERS] What can we learn from MySQL? Re: [HACKERS] What can we learn from MySQL? |
List | pgsql-advocacy |
I've been sort-of reading this thread off and on, so this may contain duplicate suggestions. I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. 1) Since MySQL AB supports and trains for MySQL, there's loads of training information available on their website. On the other hand, I had a hard time finding training information for Postgres in general. Same goes for support. It's easier to find, but it's still somewhat convoluted, IMO. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. While being somewhat nit-picky on this, it'd also be helpful if someone wasn't completely database literate could understand some of the changes. Who needs transactions, anyways? :) 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. 5) I believe that this was noted as well somewhere along the line - the other tools, like pgadmin III aren't readily available either. They're excellent tools, and they should be quick to find on the postgres website. 6) Bug tracking. I haven't really looked into how MySQL handles this, but when learning about Postgres, I discovered that the whole development model seemed kind of 'closed', and people on the mailing lists would find bugs repeatedly. Something like Bugzilla would be very helpful in this respect. I've been kind of out of the loop for the past 6 months in this area, so it may have changed since then. 7) The two Postgres books are available online for anyone to read and download. They're there, but, to me, you have to notice them on the sidebar to go to them. They're extremely helpful, and they should be pointed out more. Most of these suggestions aren't really anything to do with the database itself. It's simply a re-organization of some of the information that's already available. As others have mentioned, 'it's about the PR'. Just my $.02 worth. Tim
pgsql-advocacy by date: