gotta Iove when the article contradicts its own conclusion
|
| Author | Content |
|---|---|
| tuxchick Feb 03, 2007 9:28 PM EDT |
I do not make this up. I merely copy n paste: "In January 2005, Pervasive Software jumped into PostgreSQL support. By June 2006, it was jumping out. "We underestimated the high level of quality support and expertise that was already available with the PostgreSQL community," Pervasive president John Farr wrote to the community explaining the departure. PostgreSQL.org has about 243 developers contributing regularly plus 51,788 who have signed up for its mailing list. A support query launched into such broad expertise tends to get a quick response, says Berkus." " Its uneven pattern of sustaining support options, however, should be a warning to open source shoppers to proceed cautiously." All from the same article. No, really. |
| Sander_Marechal Feb 04, 2007 3:53 AM EDT |
Yeah I saw that too :-) Article recap: Postgres's community is so good at giving support that no commercial 3rd party can hope to match it. |
| DarrenR114 Feb 05, 2007 10:13 AM EDT |
Getting some of the information necessary to do common things can be like pulling teeth. For instance: How do I get OpenOffice.org Base to work with PostgreSQL databases? It's not exactly an OpenOffice.org issue, nor is it exactly a PostgreSQL issue. And I've had other similar esoteric issues, mainly in the area of interoperability between PG and other stuff (Apache Tomcat, PHP, PERL, etc.) PS - I do have the answer on how *I* got OO.o and PG to work together. I was just pointing out something in my experience. PPS - I don't run anything but PostgreSQL in my DB work. |
| jimf Feb 05, 2007 10:30 AM EDT |
> Getting some of the information necessary to do common things can be like pulling teeth. I like a lot of things about PostgreSQL, but is a real pita to work with, especially the interoperability with other tools. Being lazy, I usually just go to mysql which has better tools and immediately works well with knoda and OO. |
| tuxchick Feb 05, 2007 10:38 AM EDT |
Well now, that's an interesting persective darren and jim, since by their nature databases are supposed to be flexible backends to all kinds of apps. Not having that sounds like a rather significant design flaw. |
| jimf Feb 05, 2007 10:44 AM EDT |
> a rather significant design flaw Heh... Anyone that tells you that hooking up a database is a breeze is full of it. Some are much simpler than others, and, some front ends work better than others, but in reality, it's all a pita. Nature of the beast ;-) |
| DarrenR114 Feb 05, 2007 11:17 AM EDT |
TC - Don't get me wrong - PostgreSQL is a *very* flexible backend to all sorts of apps. The trouble is in the lack of documentation. And even there, I'm not certain it's so much a failing of the PostgreSQL community, as it is a failing of the other communities. For instance, when I got OO.o to work with PostgreSQL, I ended up going to three different sites to get the information I needed. My take on that particular issue is that the shortcoming was more on the OpenOffice.org side of the equation. The Postgre community has a site and forum for the JDBC connector, which is where I actually downloaded it from. I found the best tutorial for actually using it at a site with an online copy of the Practical PostgreSQL book from O'Reilly. Once I verified the proper setup for JDBC and PostgreSQL, I had to figure out how to get it working with OpenOffice.org. The problem with OpenOffice.org site is that the only information you'll find is for MySQL, and it's really not all that informative beyond MySQL. There is no reason for this. In fact, I found the instructions for setting up Firebird SQL (from the firebird.sourceforge.net site) to be much more helpful. So it isn't that PostgreSQL isn't flexible or useful - it's that the documentation for getting it to work with other apps (as found at sites supporting those other projects) isn't always so good. Getting PostgreSQL to work with PERL applications is a snap, because the DBD connector is well documented. Getting PostgreSQL to work with PHP isn't so easy, mainly because DB support beyond MySQL is relatively immature. And this is a situation that has arisen because MySQL was "good enough" for most small DB tasks that developers wanted to accomplish. But now there are more of us "hardcore" DB programmers who are used to using things like Oracle Forms and Informix 4GL. MySQL is *not* good enough for us, so the PHP community is now providing things like "metabase". Now all I have to do is take the trouble to backport all those MySQL function calls to the metabase equivalents. Shortsighted impatience has brought about a de facto state of "vendor lock-in" giving preference to MySQL for things like PHP and Python. With OpenOffice.org, I find the documentation emphasis on MySQL to be a little shortsighted since the default DB is Hypersonic SQL. And then there is the outdated concept that PostgreSQL is hard to manage. Most DB developers aren't aware of things like PgAdminIII, which provides an easy-to-use GUI interface to PostgreSQL. Again, it isn't a matter of shortcomings for PostgreSQL as it is a matter of "developer inertia". As a word of endorsement, like I stated before, PostgreSQL is my DB engine of choice. |
| bigg Feb 05, 2007 11:30 AM EDT |
Maybe one of you can answer this question. For the work I do, mysql is pretty easy to set up and use, and has lots of documentation of the "for dummies" type. The documentation is rather weak IMO for postgresql. But that's not why I use mysql. I have always been told that mysql is much faster than postgresql. Is that your experience? Or is that a myth? |
| DarrenR114 Feb 05, 2007 12:28 PM EDT |
bigg, In my experience, PostgreSQL has not proved slower than MySQL. Where this impression that MySQL is faster comes from is that a few years ago, MySQL did not support Transactional reliability and PostgreSQL did. This was not really an issue with many web developers because if they were using MySQL, it was usually for small, personal projects. Who cared if an entry "disappeared" in a Blog? Reliability was not as big a concern as speed. This always annoyed me - if data isn't important enough to store reliably, then it isn't important enough to store period. The speed difference has pretty much disappeared now that MySQL is supporting transactions. But there are other enterprise-level features that MySQL does not natively support, if at all, such as sub-selects. And last I checked, which wasn't all that long ago, MySQL is still not fully ACID-compliant out-of-the-box. This makes it unsuitable for many enterprise-level operations. Then there's the security issue with MySQL being able to be run as 'root' with all the potential exploits that entails. I understand there's a workaround now, but any allowance to run any DB engine as 'root' is just plain idiotic. I also don't like the licensing scheme for MySQL - since you're going to be using MySQL in a commercial environment, you did remember to pay for the licenses, didn't you? As for book documentation, I've found several good books devoted solely to PostgreSQL programming, such as "PostgreSQL Developer's Handbook". Also, if you like the books from WROX press, you'll find "Professional Linux Programming" to be a very good book for building an entire integrated system, including web programming, kiosk terminal programming, and database programming. It goes into decent detail why they selected PostgreSQL over MySQL for their approach. That's my take on some of why I prefer PostgreSQL over MySQL. |
| Sander_Marechal Feb 05, 2007 12:54 PM EDT |
Quoting:I have always been told that mysql is much faster than postgresql. Is that your experience? Or is that a myth? My experience is that MySQL is faster at reading and Postgress if faster at transaction processing. Which makes MySQL good for sites (many reads, few updates) and Postgress better as an application backend or data warehousing backend. |
| jdixon Feb 05, 2007 1:42 PM EDT |
What sander and DarrenR14 said. :) From my understanding (I don't do database work), Postgress is fine for what it's intended to be used for, which is industrial quality database work. MySQL can be faster, as it has more options for personal vs industrial level work, but if you configure it to the same specs, it loses its speed advantage. |
| swbrown Feb 05, 2007 10:17 PM EDT |
MySQL is fast if you don't want it to act as a database. If you do, it's dog slow compared to PostgreSQL. |
| bigg Feb 06, 2007 7:13 AM EDT |
Thanks for the info. I don't like to rely on only one software package for anything, so perhaps at some point I will pick up postgresql. I didn't want to mess with it if it had speed problems. As for the license, my work is all GPL when it is distributed, so I'm okay in that regard. I do hate license complexity but it is something I am willing to put up with. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!