Re: native xml processing vs what Postgres and Oracle offer

rpost wrote:

> In short, I think the main issue in picking attributes and keys here is
> not in determining how the data is to be used, but in determining
> realistic commitments from the supporting software on the accuracy
> of the attribute values supplied. For a web forum, <author, timestamp>
> seems a good choice of key, even if they aren't always accurate, as long
> as the server never accepts multiple messages with the same author and
> timestamp.
>

This is why web-based forum coders (working with a relational database at the back end) don't like "threading."

...it's hard to do and you pay a huge performance penalty to make it happen (with relational modeling anyway). So relational programmers fool themselves into thinking hierarchies are bad design. Hierarchies are not bad design, they are the weak underbelly of the relational model.
Hierarchies are part of the real world. They just don't fit well into the relational scheme of things.

With XML querying hierarchies is a snap. So if you have a hierarchical problem, XML is a better technology.

Someone referred to XML as messy technology that couldn't be optimised. But SleepyCat and XPath is faster than any relational system running any one of the ugly, complex and slow-as-mollases "relational solutions" to the hierarchical problem.

For some problems you don't need a database at all: grep or perhaps lucene or HyperEstaier are all that's needed.

For some problems XML is the best choice, particularly if the data is naturally hierarchical.

For other problems--particularly for *large* data problems--relational systems are the best choice....but almost never when hierarchies are involved. Received on Thu Jan 01 2009 - 01:47:51 CET