"Quirk" <quirk / syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405060711.176b495d / posting.google.com...
> "Sarah Tanembaum" <sarah.tanembaum / yahoo.com> wrote in message news:<c78jfi$vomj$1 / ID-205437.news.uni-berlin.de>...
> 
> > Is PostgreSQL reliable enough to be used for high-end commercial
> > application? Thanks
> 
> Some rules of thumb, A guide to the perplexed:
> 
> - If you don't have the source code for a product, and the right to
> modify and redistribute it in perpetuity, nothing you develop on top
> of it can be relied upon, so therefore the open source applications,
> or applications for wich you've been granted such rights via an
> non-expiring licence, are much *MORE* suitable for high-end commercial
> applications, since you are not locked into any external dependencies.
That's not true. The main problem is not the right to the source code
but the right to get maintenance.
An example: How many corporations had UTF8 built into oracle before
the UTF8 enabled distribution came out?
Who implemented ANSI PL/SQL for mysql before the mysql developers did?
The right to modify is a red herring. If I'm prepared to spend man-years on having
a developer work itself into postgresql or mysql (plus set up all the QA stuff)
I can also ask any other db company for the price of a feature. Or, in case
of old versions, buy vintage support.

> 
> - Ideally, your Application's data access will be built around a data
> abstraction layer that can use alternative database backends, i.e.
> PEAR::DB.
Which either gives me the freedom to write nonportable code
("create bitmap index", "where A(+)=B") or loses efficiency
on all but the dumbest platform.

> 
> - If your data is really important to you, you will use network, not
> application or database level security to protect access to it.
Wrong. If it's important it must not matter whether one tries to
access the data from a local or remote machine. A defense in depth
will always include a securely configured database.


> 
> - If your data is really important to you, you will only keep a
> secondary copy of it in *ANY* SQL server for indexing and querying
> purposes, not as the primary datastore.
The primary store is the safe with the tapes of last night. So what?

> - Your primary datastore should be self contained, self describing and
> human readable, something like a heirarchy of XML files. This is the
> best way to ensure the perminancy and portabilty of your important
> data.
Until the next version can't read the old format (or DTD in the XML case).
In any case, permanency across more than two major database or other
software releases is difficult, regardless of the format.

> - Anyone who calls Free Software 'Freeware', implies that believing in
> it is a 'religion' or thinks that it is low quality as a rule should
> be considered unskilled labour, not a source of real advice.
It's not "low quality" as a rule, at least not as long as one reduces product
quality to code quality. The problem is that as soon as the developers feel
they are fed up with the product or get a real job they dump the code
on you and leave you alone with it. They get nothing, so they are not
required to do anything.
So, I'd only trust mysql if I could do a contract detailing response times,
recovery services, a patch process and all that. Since I then have to
pay anyway, I might as well go for the company that's best at it. Oracle
has a reputation for that and after 5 service requests I've never been
disappointed yet. No idea how IBM or M$Soft do in the service area.

Lots of Greetings!
Volker