On Tue, Dec 20, 2011 at 1:39 PM, Kent Tenney <[email protected]> wrote: > On Tue, Dec 20, 2011 at 12:24 PM, Seth Johnson <[email protected]> > wrote: >> On Tue, Dec 20, 2011 at 12:58 PM, Kent Tenney <[email protected]> wrote: >>>> >>>> In my architecture, nodes point up to their parents. >>> >>> How do you maintain sibling order? >>> >>> I've been settling on node "addresses" in metadata, >>> it's a list of child indexes. It provides each node with a >>> self contained description of where it lives, which I like. >>> I haven't come across a more succinct way to do that. >> >> >> A counter field that you add to an index on the parent key field. >> >> So you search for the record that has no parent key -- that's the top. >> >> Then you search for that record's key in the parent key index -- that >> will have its children in sibling order. >> >> And so forth. >> >> I don't do SQL searches, which would probably make this slow, just a >> local navigation algorithm on the index. >> >> You seem to have hit on something similar to my scheme with your self >> contained descriptions of where nodes live. The records I'm speaking >> of are just fields holding keys in that uniform structure I speak of, >> so each record holds the context -- plus the particular "node" key, >> which I call a link. >> >> "Nodes" are actually also metadata -- you don't really get "data data" >> until you seek attribute values. > > It sounds like the moral equivalent of a linked list. > > The "address" approach I've been leaning towards feels more > robust / useful, but I haven't implemented with it, so I really > don't know. It seems like what you describe is closer to the > "node and edge" world view that graph software uses. > > In the web framework world there is a similiar dichotomy, > mapping urls to content vs. traversing url paths.
A linked list where every "node" has the context fully specified. And the fact there's only one "tree structure value" per record (the parent key) keeps things simple, with everything in a simple, flat denormalized data structure that's as fast to work with as conceivable, as well as massively scalable -- perfectly amenable for NoSQL backends, for instance. That flat structure lets you extend the basic concept of db relations to what I call a context (so it has all the functions you need regardless of specific context, rather than being simply joins of two tables representing particular entities in the real world). Seth -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
