Re: What so special about PostgreSQL and other RDBMS?

quirk_at_syntac.net (Quirk) wrote in message news:<4e20d3f.0405070046.50c2d5dd_at_posting.google.com>...

> ... 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 Received on Fri May 07 2004 - 12:16:28 CDT