> > But that is not what I was talking about either. I was talking about
> > the relational model as the basis for storage, not a database
> > design.
> > ...
> > Do note that "performance" has nothing to do with "relation model"
> > as the basis for data storage.
> >
> > Nor does "OODBMS" have anything to do with performance, but
> > rather with "API" or "interface". Or at least, it should ;-)
>
> Stop-stop-stop. You want to decompose an XML into pieces, execute a
> query on that pieces with SQL and then combine that pieces back to the
> original XML? You want to use relational database as a storage, burn
> your CPU and IO cycles, build an API that tries to resolve that
> impendance mismatch only because you want to have relational data store?
>
> > I am open to suggestions, I'm just not easily convinced :-)
>
> There is no point to try to convince you if performance means nothing
> for you. Just at some point you will be beaten by some more
> open-minded company/person when struggling for an important contract.
> And there will be no buzzwords used, but just plain API and
> performance measurments.

Roman, "performance" is NOT a property of the "relational model".
There is no discussion possible about that.

I'm also NOT saying that OODBMS xxx could not perform better
than (OO/XML)DBMS yyy on operations zzz and project aaa.

What I am saying is that:

1) data should be stored in such a way that there's no redundancy
2) data storage should have a solid foundation and operations defined
3) IMO, XML documents stored as a whole, does not meet 1 + 2

I fully understand that it might be easier to store a complete XML
document and create a separate language to query them but I do
question if it should be done in the first place and if XML isn't
extended to far beyond its original purpose.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com