|
I think that any simplistic approach to shredded
storage of an XML infoset in relational tables is likely to be extremely
inefficient. Just think about the problems of representing
namespaces.
There are techniques that can make storing hierarchies
in tables viable, such as the adjacency list model pushed by Joe Celko (see http://www.ibase.ru/devinfo/DBMSTrees/sqltrees.html),
but the fact remains that if you want to store a hierarchic structure, storing
it in the rows and columns of a relational database would not be one's first
choice.
Michael Kay
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
? 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 ?
I don't have
enough time immediately to do it but soon I will if you think it might be
interesting...
Alain COUTHURES
<agenceXML>
Bordeaux,
France
http://www.agencexml.com
Michael
Kay a écrit :
875E9EC6471744C98DBCC0FC6F61B9D5@Sealion type="cite">
All of which led me towards Cocoon and then Orbeon...
* You use XHTML+XForms as your templating language.
* You use REST and XQuery to interface with services and
XML databases.
I'm only a couple of days into it, but it appears you could
happily create your XHTML + XForms using XSLT 2.0 and that
could be really powerful. Hopefully I'll understand a bit
more on that today...
One of my clients has been using this architecture successfully for several
years. User input comes in as an XForms instance, XSLT (Saxon) takes this
instance as input and either generates or parameterizes a query on the
(Tamino) database; the output of the query comes back as XML, and goes
through another stylesheet which generates XHTML+XForms, and the cycle
starts again; all controlled by an Orbeon pipeline. Works very well, except
that it can be tempting to make the pipelines too long, at which stage you
start to lose response time, especially if they include metastylesheets,
which is quite often.
The experience with Tamino - and it's mirrored by another client who uses
DB2 XQuery - is that it's best to keep the queries simple if you want to
have a good chance of them being executed efficiently. Concentrate on
getting the data you need, and don't give the database engine the extra
burden of doing any complex analysis of the data, or formatting it for
display: that's better done outside the database engine in XSLT code.
Michael Kay
http://www.saxonica.com/
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
|
