On Fri, Jul 11, 2008 at 5:34 AM, COUTHURES Alain
<alain.couthures@a...> wrote:
> I also think that XSLT and XPath are powerful enough for, at least,
> MS-Access level applications and I would like to know if anybody already
> tried to define a relational database model to store XML tokens (a table for
> elements, a table for text nodes, ...) the way a parser could do it in
> memory ?

I did a version of this for a very handling a specialized streaming
XML feed.  The feed had no well defined schema and things where always
being added to it.  We knew what data we wanted for the most part but
also wanted to be able to go back and look at the feed and see what
had been added to it any point.  Worked ok, for  the purpose it was
intended, but there wasn't a lot of complexity involved anywhere (no
entities,l imited name spaces).

> It would then be a layer integration problem to be able to access
> such a database from an XSLT engine...
>
> Considering that today machines are effectively powerful and that RDB cache
> is a key for performance, do you think that nonetheless it would be too
> dramatically slow ?
>

In our case it was only a part of the data and some associated
metadata that we where after. For the most part, we didn't attempt to
put things back together after we had shredded them.  I think, for any
high query volumes you'd want to essentially push the results of any
such database to a denormalized version of the DB or a specialized XML
database as otherwise you'd end up with many self joins to the same
tables and performance would indeed be an issue. IOW, the database
normalized for the XML element / attribute view is for analysis
purposes, not for production queries.

-- 
Peter Hunsberger