Slashdot Mirror
PostgreSQL vs. SAP?
Johann asks: "As my friend and I embark on building a large web site using open source development tools, I planned on using PostgreSQL. I was reminded that another 'enterprize' database is now released under the GPL - SAP DB.
Since there have been countless Pg vs. MySQL comparisons on Slashdot, I wanted to ask: how does SAP DB compare technically to Pg?"
I love PostgeSQL - it's worked wonderfully for us, but....
In all seriousness, if you use SAP DB, you could probably raise your rates just due to the SAP name alone. The name 'SAP' is also good for covering your ass when things get difficult.
SAP and Oracle have expensive reputations and you can charge accordingly. We do it all the time, for some of our nastier customers, when anything with the word 'Cisco' on it need care.
It depends on the relationship you have with your custome, wether you go that route, but it's worth considering.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Also Slashdot now numbers each and every post uniquely. Contrary to popular myth, this was not done to reduce FPs. When they needed two fields (the story number and the post-within-story number) for their primary key, they took a nasty performance hit.
So if we use Slashdot as an example (and I have to admit it's the only big MySQL application I know much about), then we have to conclude that MySQL's much-touted performance lead goes away if your database has more than the most trivial structure, or if your database gets very large.
Funny. I thought the documentation was pretty readable myself, most of the syntax stuff looked similar to BNF.
something strange going on here ;-)
http://www.sapdb.org/history.htm
I guess I had similar problems:
First of all the binary downloads of PostgreSQL don't seem to include the enterprise jdbc drivers (implementations of the interfaces in javax.sql.*) which I wanted to use to implement connection pooling in an application using jdk1.4.
Downloading the latest PostgreSQL from cvs (a few months ago) did appear to include the source for this, however they wouldn't build with jdk1.4 due to many new methods having been added to the interfaces since the implementation was last updated (and even many of those that were there will just throw an org.postgresql.Driver.notImplemented exception).
By modifying the source to add implementations of the missing methods to also throw notImplemented exceptions I have successfully built some drivers which appear to work correctly with my connection pool manager (and having since then got a proper internet connection have gathered from the mailing lists and news groups that other people have done the same thing).
The problem with this is that you no longer have a program that just works out of the box. (and building from source also entails either creating or suitably modifying some init.d scripts)
OTOH it was an educational experience, and made me seriously consider learning more about PostgreSQL and maybe trying to join the development effort (though I haven't actually done so yet, too many other things have come up)
I have also used the C++ interface, which seems to work O.K, but it is much less powerfull than the jdbc implementation could be if it were to implement some of the cool features such as writable result sets and prepared statements that the java interfaces declare (but which PostgreSQL doesn't yet implement)
I agree on about everything but point 11 :
Warning, total subjectivity: something about PostgreSQL seems "clean," compared to MySQL. I can't say what it is, but there is a big lack of business-likeness to MySQL, other than what I listed above
I'm following pretty closely both releases and frankly I've the exact opposite feeling. While MySQL adds features one by one, Postgresql seems to absorb lots of stuff at each releases. While this is great feature-wise, it can lead to pretty nasty bugs and instabilities.
Just look a the latest release for example (from postgresql history) :
"it fixes a critical bug in v7.2: sequence counters will go backwards after a crash "
That bug is really critical (can you imagine the state of your datas when counters go backward ?), but it took 2 months to be discovered and fixed. On the other hand the MySQL history list only very minor bug fixes, most of them that you are highly unlikely to meet and that are of little effects. Actually the MySQL developpers make the effort of documenting every petty bug fix, which is a very professional thing.