[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) <len.bullard@intergraph.com> writes:
>
> That's the solution I've used and has been used since
> time immemorial in yeOldeDocumentDatabases. Locally,
> we call it a joins table.
Sounds similar, probably a little different in the details: we
normalized out references to the tree structure leaving "naked" tree
structures in the tree table and reusing them as needed. (We have
different "views" of the same tree, I'm not attempting to reuse
structure across different trees, I don't think that would make sense.)
It took a lot of performance testing to convince us that was worth the
extra work, but it is both space efficient and performant.
> I once implemented a
> treeview object for such and it was the one time
> that namespace URIs really came in handy. When we
> have to create ERDs and document tables, pulling all
> of the relationships into a simple meta-table is
> useful and avoids sparseness.
The other thing is that once they are in the same table it becomes
really easy to build out the graph structures: new cross cutting views
add a new tree, but hardly any additional logic is required to exploit
it. At most you end up adding a new reference table that normalizes out
the indexes for a particular set of trees, but that's mostly to
partition the indexes for performance purposes (I've posted about this
before). Having said that, it also helps the developers by giving them
a focus for organizing the stuff that deals with a particular context:
adding yet another set of type tables to an already abstract structure
isn't very human friendly after a while...
> The external pointers approach comes in handy when
> one has multiple endpoints in files/entities/things
> of different formats. That is why Hytime originally
> required notation declarations and there was a concept
> of link types. The local anchor identifies the
> link which identifies the notation which identifies
> the target type handler. So the function/dll is named
> and is passed the link type and the identifier for
> the target. The target might be read-only and might
> not be markup and might not have locally stored
> names for location purposes. So Hytime had types
> such as nameloc (where a name can be used), treeloc
> (what got into XPointer and XPath), and so on. One
> could use byte offsets for links, and so on. There
> is set of constructs for using dimensions so it was
> easy to do what HTML later did with maps.
>
> Most use namelocs and treelocs and the dimensional
> locators that I've encountered.
It sounds like you are saying that you think adding some external
pointer structures would suffice for moving XML to XML++ (or whatever)
???
> len
>
>
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
>
> Hmm, we set out to implement a tree management database and
> ended up building some limited forms of graphs out of it.
> You end up cross referencing the nodes in the trees via
> another table. Sounds like the same thing attacked backwards.
>
> > graphs
> > can easily represent very complex sets of relationships - something
> > trees will never do. to me this means xml must struggle as
> > application
> > or document complexity increases,
>
> I've been trying to say exactly this throughout this thread,
> thank you for the succinct way of putting it.
>
> > so there will be a
> > requirement for a
> > meta-xml (MXML?).
> >
>
> I'm still wondering if something like Gavin's external pointers on top
> of XML wouldn't suffice?
>
>
|
