On Tue, 13 Feb 2001, Paul M Foster wrote:
> Let me echo this. I have _never_ been on a list where so many of the
> developers of a product were subscribed as well. And these folks
> provide _very_ considerate and clear assistance. Hats off to them.
Yah. What I find is the developers set the general tone/culture of the list.
This affects the type of responses/support you get even from the other list
subscribers. So it's quite good here where you have kind and helpful developers.
As for the original question. I find in a corporate environment it boils down to
who you want blame to fall to - blame tends to flow down the payee channels.
For accounts and order processing it's probably Postgresql/Oracle/DB2.
If you have a resident DBA, get the DBA to pick the database. If the DBA is you
well then if you have lots of money you may wish to pick Oracle/DB2 - because if
you're new to DB stuff and doing major stuff, you'll probably need to blame
someone else ;). If there's very small budget then it's Postgresql, but make
sure your bosses know that they're getting a lot more than what they paid for
;).
That said, installing, configuring and maintaining Postgresql is a lot easier
than Oracle/DB2. For instance there's a lot more "backward compatibility"
ugliness in Oracle. So in a less "corporate" environment I'd say go with
postgresql.
Performancewise with these three the main factor is probably going to be
how the DBA organises the data and forms the queries. The DB engines of all 3
are quite decent once you know about their various quirks[1].
Cheerio,
Link.
[1] I've come to a conclusion that if it doesn't have strange quirks it's not
an RDBMS.