Re: What so special about PostgreSQL and other RDBMS?

[e-mail] (Quirk) wrote in message news:<[e-mail]>...

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

Son, it sounds like you're the victim of some simplistic advise from
database 101 book:
1.  database portability is not (typically) as important as
application portability - since applications come & go far faster than
databases change, and some databases support multiple application
technologies (java + .net, php + python, etc).
2.  abstraction layers can often cause more complexity than they
solve, unless the project is fairly sizable
3.  the most powerful SQL capabilities are seldom supported in
abstraction layers - living without OLAP capabilities, for example,
means that you're limiting the usability & functionality of the
application.
4.  having said all that - yeah, go with portable sql as much as you
can, and only deviate if there's a value in doing so.  But don't work
yourself up into a religious hysteria about it.


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

Don't be a fool, implement security measures on each level.


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

That's a damn funny idea - now exactly how do you plan to keep the
6000 tables from a SAP financial database for a fortune 100 updating a
hierarchy of XML tables?  You realize that the database is never
static, that performance & quality are already tough challenges
(without non-acid writes to XML files).  And you must also realize
that nobody will care about that detail of that data in 30 years,
right?  Oh yeah, and if you *really* want to archive it you'll keep it
on non-acid paper instead of in an electronic archive.  Now - getting
transactions to span a print-device - that would make for an
interesting little undergraduate project.

Here's the thing - you've got yourself a nice objective there, and I
encourage you to pursue it.  Just keep in mind that complex XML isn't
"human readable", that it doesn't contain sufficient business rules
and integrity constraints to be fully "self describing" either.  So,
ten years from now if you really wanted to read that data (and most
often you won't) you really won't have a clue what it means - due to
the massive loss of context.  Sure, you'll be better off than if you
had a file format you couldn't read at all - with XML you'll probably
be able to find a way of structuring the data (got help you if you
can't).  But you will still have  spent a lot of time & money on a
solution that'll fail you in the end.

So, you've got yourself a fine start on database technology.  Now, go
get yourself a job, keep these objectives in mind, and in a few years
discover the wisdom in what Yogi had to say:
"In theory there is no difference between theory and practice. In
practice there is."


Buck