> Well, it is probably not that easy to come up with such an architecture at large.
Right ;) > In your use case, I would suggest to not use same name sibblings - > use a counter or some other id to name the nodes. I assume this would > already solve many (if not most) of your performance issues. I was actually thinking of naming my nodes with some kind of "business ID" or something (thinking in progress) > Regarding hierarchy: There is no single rule to this. Given your contracts > (and other) lists, you could structure by geograhic location, by a number of > leading characters in the customer name, by contract year, whatever. Full of good ideas there, thanks, but I must keep an ease-of-use for other use cases, like administration, automatic node creation, movement, refactoring and so on, and such categorization may lead to the multiplication of (easy or not) use cases (like changing a contract date would potentially require to move it from a catgory to another...), so modifying the architecture is a brainstorming issue. I appreciate very much your proposals , thanks a lot !! > Maybe, if you drop same name sibblings, you might not even be required to > introduce hierarchies. This is also what I've been thinking, and why I'm planning to try another naming pattern and test again performances. I'll definitely inform the community of results. Frederic Esnault
