Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Why Multipath (LCA) Hierarchical Query Processing Works

From: Peter Hunsberger <peter.hunsberger@-----.--->
To: mike@-------.---
Date: 8/3/2009 4:10:00 AM
On Sun, Aug 2, 2009 at 10:25 PM, <mike@a...> wrote:
> Basic ANSI SQL inherent hierarchical processing using the Left Outer Join to
> model and processes hierarchical structures is basically quite obvious and
> empirical and I have covered this in my previous SQL/XML articles. The proof
> for multipath hierarchical query processing which requires Lowest Common
> Ancestor (LCA) processing occurring naturally in ANSI SQL is not that
> obvious because it is truly quite amazing since it was never designed into
> ANSI SQL and is quite complex to perform. Empirically it can be proven from
> its results, but it would be very nice to know how and why it is working so
> we can absolutely trust the results. I have written an article describing
> the how and why of natural LCA processing in ANSI SQL and have appropriately
> entitled it “The Ghost in the Machine”. It can be located below.
>
> The Ghost in the Machine
> http://www.tdan.com/view-articles/11069
>
> This LCA processing in XQuery is not automatically performed today and is
> too complex to do with procedural navigation. This problem has been
> researched academically and attempted solutions use LCA functions that have
> to be inserted correctly by the query user which takes away for its ease of
> use and schema-free purpose. My work with LCA processing has shown that LCA
> processing can involve nesting LCA’s that I do not necessarily see occurring
> in this LCA XQuery research limiting their future solutions to more simple
> queries. ANSI SQL performing LCA processing automatically has no multi-path
> LCA query limitations. This has been referred to a LCA query processing, at
> least three decades ago.

Mike,

Perhaps I'm missing something here, surely you're not really
suggesting that we should code outer joins to manage hierarchical
structures in a relational database?  Why not just use Celkos set /
subset tree management (or other related algorithms)?  We've got some
tree structures several 1000 nodes deep and wide managed in a
relational database, can you me exactly how you would go about finding
(for example) all the leaf nodes for such a tree?

-- 
Peter Hunsberger

_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent