Re: What so special about PostgreSQL and other RDBMS?

[e-mail] (Buck Nuggets) wrote in message news:<[e-mail]>...
> [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:

Ok Dad, it sounds like you're the victim of the patronizing ass school
of discourse. My condolences to your coleagues.

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

Both are important, which is more important depends on the data and
the application, in both cases my advice to either rely on open
standrads or abastract access when possible holds true.

> 2.  abstraction layers can often cause more complexity than they
> solve, unless the project is fairly sizable

I agree, when you have the perpetual right to the database and It's
source code, but if you are using a proprierty database then not using
an abstaction layer is folly, unless the project is so small that the
code is disposable.

Abstracting your data access can be as simple as writing a function to
use as a wrapper OR as complex as a full blown data access object,
depending on the application.

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

I have no argument here, as so far this is true, but experience
prompts me to bring up two points: First is how often are 'powerful
SQL capabilitites' used to compensate for poor database design?
Second, how certain are you that Proprietary databases (in fact than
YOUR particular one) always have more features than Open Source (or
Competetive Alternatives) ones to justify engineering your application
so that you are dependant on it forever?

I know, the answer is 'depends', but I hope you see what I'm getting
at.

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

I agree, I never said anything different, the only time you *must*
abstract your data access is when your application and/or it's data
has a long expected life time and depends on a prorietary Database.

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

OK Mr. T.  I agree. What I was really argueing against where those
(like Volker) who think that Database security is a replacement for
network security, I'm trying to make it clear that network security is
more important, since databasy securite depends on it, although, yes
both are important.

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

I'm a funy guy, always good for a laugh or two.

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

It was only an example, one that for some applications makes sense,
you can always randomly chose an example wher it does not make sence
but this, my silly friend, is what is know as a straw man.

I guess this would be a good time to mention that SAP has been working
closely with MySQL these days.

>  You realize that the database is never
> static, that performance & quality are already tough challenges
> (without non-acid writes to XML files).

Yes I do realize this, but don't let my understanding discourage you
from further random blather if it makes you feel smart.

>  And you must also realize
> that nobody will care about that detail of that data in 30 years,
> right?

To bad you didn't realize that I never suggested otherwise.

>  Oh yeah, and if you *really* want to archive it you'll keep it
> on non-acid paper instead of in an electronic archive.

Perhaps, but paper is not always superior to some sort of WORM
storage, provided you use an intellegent storage format, my main point
is that an imcomprehensible file system blob, readable only by a
deamon for wich you have no source code, is not such a format.

> Now - getting
> transactions to span a print-device - that would make for an
> interesting little undergraduate project.

I would consider redundant WORM devices instead.
 
> 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.

Thanks for the XML tips.

Sheesh. Where were you when I was writing my Pull DOM to DOM parcer?

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

Ok so your argument amounts to that since any approach *MIGHT* fail, I
should recomend the aproach that *WILL* fail?

What the hell are you trying to say?
 
> 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."
If I happen to meet the unemployed, inexperience person you imagine
you are talking to, I'll tell him that the ignorant pompous ass says
hello.

Cheers.