From: Austin Ziegler <Austin.Ziegler@...>
Date: 2004-05-07T04:24:14+09:00
Subject: Re: What so special about PostgreSQL and other RDBMS?

> quoth Quirk on 6 May 2004 11.14
> 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.

This is not particularly useful advice. Although I am a good
database application developer, in no way would I ever consider
myself a database engine developer. There are times when the
commercial products are significantly more usable and stable than
equivalent open source projects.

> - Ideally, your Application's data access will be built around a
> data abstraction layer that can use alternative database backends,
> i.e. PEAR::DB.

This is reasonable advice, but it also restricts you to the barest
minimum of functionality from a database.

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

No, if your data is really important to you, you will use network,
application, and database level security to protect access to it.
Additionally, you will use extensive validation and redundancy.

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

This is downright *BAD* advice, bordering on idiotic. Your primary
data store should be in the format that makes the most sense for
your application. You don't choose XML necessarily because it is
exceedingly poor at representing relationships between data items
except for hierarchical representation. You don't choose a
relational database necessarily because they are *hard* to get right
(harder than they should be, but there is also the concept of
relational algebra that most people just don't get).

The best advice is to ignore this last guy's advice.

-austin
--
austin ziegler * austin.ziegler@evault.com