[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall <rjm@zenucom.com> writes:
>
> Elliotte Harold wrote:
>
> > Hunsberger, Peter wrote:
> >
<snip>discussion about the state of the art in graph tools</snip>
> when i designed a graph based data base i only set up to specify the
> vertices and edges. i noticed a couple of things from this.
> the graphs
> can't be easily represented in 2 dimensions (let alone 1) (there's a
> whole body of work on flattening graphs to n dimensions), but
> they can
> be easily traversed. any application actually uses a tree
> with it's root
> as one of the vertices. the edges have a nature of their own that
> determines whether or not an edge can take part in a tree. cycle
> detection is essential when constructing the tree. machine
> traversal is
> relatively easy even if visualisation is hard (cf a klein
> bottle). etc.
> there's some concept that the object-relational database (sort of an
> oxymoron really) is a graph based data base as well.
That makes sense. I think (well I'm guessing) you can show that any
graph can be implemented in any relational database, so therefore in any
object-relational database.
> i had to
> introduce
> an "alias" concept in the general sense to make trees out of
> graphs that
> wanted to reference the same vertices, but in different
> contexts.
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?
|
