Re: What so special about PostgreSQL and other RDBMS?

> > - 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. 

Yes it is.

> The main problem is not the right to the source code
> but the right to get maintenance.

With out the right to modify the source code you can have no "right to
maintenenence" as all rights are held by one vendor, exactly the sort
of dependency I recomond avoiding.

> The right to modify is a red herring.

Not if your application and the permenancy of your data is important.

> > - 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.

You can always write bad code, my point being that if you are using a
commcial SQL server, such as Oracle, you should abstract your data
access so that you can use something else instead down the road, you
can do this with your own wrappers through elegent coding, or use a
class such as PEAR::DB (for PHP), depending on what your application
requirs. Efficiency is very relative, eficiency of what? Code
Executution? Application Extension? Interoperability? Tip: The first
is not always the most important.

> > - If your data is really important to you, you will use network, not
> > application or database level security to protect access to it.

> Wrong.

Famous last word(s).

> If it's important it must not matter whether one tries to
> access the data from a local or remote machine.

Interesting that you believe that this can not be accomblished with
network security.

> A defense in depth
> will always include a securely configured database.

Yes, a securely configured database, protected by a secure network,
the later being far more important!

> > - 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?

Not only last night, but also perhaps thirty years later, or maybe a
hundred in the case of public data, which is why some incomprehensible
filesystem blob, accessible only through a deamon for which you do not
even have the source code will not do, rather as I say, self
contained, self describing, human readable files. The filesystem blob
is designed for optimized access not perpetual storage.

> > - 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).

What is it about "Self Contained, Self Describing, Human Readable"
that you do not understand?

> In any case, permanency across more than two major database or other
> software releases is difficult, regardless of the format.

For unskilled labour, yes. That is why vendor educated developers who
can not see passed their favourite commercial product should not be
asked for advice on this subject.

> > - 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.

If you have the source code, you are the developer, if you contract an
outside developer or licence an existing product, fine, as long as you
have perpetual access to the source code and the *right* to modify it,
or contract someone else to. If you do not, than you can not gaurantee
the permenance of your application.

Cheers.