This is akin to what some of the XQuery/relational vendors are doing: except
that they push as much of the query to the database as possible, to make
maximum use of indexes.
In principle you could implement the XPath data model directly as a view of
the database, but relational databases are much happier doing a small number
of large queries rather than millions of small ones. (If only we still had
Codasyl databases...) Saxon's NodeInfo interface is actually slightly higher
level than the XPath data model as described in the specs (because it
supports navigation using the XPath axes) but a direct mapping of this
interface onto SQL would still be a rather significant challenge, and
wouldn't give as good performance as systems that translate whole FLWR
expressions into SQL.
My first instinct was having the xpath processor calling
methods internal to the database (whatever the database uses to
lookup its data after parsing SQL).. seemed like trouble to
marshal the query into SQL only to have it reparsed by the
database engine.. but I guess that shouldn't involve too much
overhead anyways... not to mention being able to use it with
different databases.... certainly performance would be an
issue regardless...
I hadn't looked at Xquery and FLWR expressions... or the
efforts at pushing those queries into the database... thanks
for the tip... am reading up on them and the sql extension
now..
Maybe they'll get me closer to my 'holy grail'. :-)
-Brian
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--