>
I don't understand why more frameworks don't copy this basic structure.Lots of problem domains are difficult to model as trees because often, a node can be logically assigned to multiple parents, but the tree model requires it be physically assigned to only one.
Recently I bought a prepaid SIM card for a trip I am making to the USA.
In my bookkeeping system, I could enter it either as a transaction against the "Telephone & Internet" expense account, or I could enter it against "International Travel". What I can't do, because trees require mutual exclusion, is enter it under both. That breaks the model.
If instead Renaissance accountants had understood sets and relations, I might be able to log it against both and then derive whichever view of the data was necessary.
And that's the problem with hierarchical data. It privileges one and only one view of the problem domain. As soon as you need some other view, you are in trouble. If your project management system organises by project, then getting per-staff reports is now much harder. If your class hierarchy views A->B as the natural order of creation, what happens when you come up with cases where C->A but not C->B? You can't: you have to introduce complicated workarounds.
Hierarchies are simple to understand on their face. But they quickly come apart when faced with the real world and ad hoc queries about the state of the real world.