[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Why Multipath (LCA) Hierarchical Query Processing Works Au

• From: Peter Hunsberger <peter.hunsberger@gmail.com>
• To: Robert Koberg <rob@koberg.com>
• Date: Mon, 3 Aug 2009 11:52:55 -0500

On Mon, Aug 3, 2009 at 11:18 AM, Robert Koberg<rob@koberg.com> wrote:
> Peter,
>
> Don't suppose you can post your schema and some examples of how you use it?
> It sounds very interesting.
>

Afraid not, the institution licenses it for external use and I can't
step on that process.  However, the basics are simple enough you
basically want something like the following:

   tree                tree_node          data_item
----------------       ------------------       -----------------
tree_id (pk)  --> tree_id (pk) <---  data_id (pk)
     .                 left (pk)              type_id (fk)
     .                 right (pk)                   .
         .
     .                 data_id (fk)                .
        .

            .

If that comes through  in any decipherable way.  Here "tree_node" is
organized into a hierarchy using Celkos set / subset pattern, or
perhaps Tropashko's nested intervals implementation, depending on your
requirements (Ie; if you need to index sets of nodes containing given
points).  Depending on your requirements for strong typing, there is a
trick here with how you use the table (or tables) on the data side,
but that starts to get into the stuff that I probably shouldn't
discuss in public (and is only peripherally relevant to the issue at
hand)

We can talk more off list, if you want to pursue in detail...

-- 
Peter Hunsberger

• References:
  • Re: Why Multipath (LCA) Hierarchical Query Processing Works Automatically in ANSI SQL
    • From: mike@adatinc.com
  • Re: Why Multipath (LCA) Hierarchical Query Processing Works Automatically in ANSI SQL
    • From: Peter Hunsberger <peter.hunsberger@gmail.com>
  • Re: Why Multipath (LCA) Hierarchical Query Processing Works Automatically in ANSI SQL
    • From: Robert Koberg <rob@koberg.com>