[Database != Slow] Compared to memory - there's a factor of several orders of magnitude.

Databases don't have to run from disk. For dedicated uses, I agree that some hand-built structure is probably faster. However, when you start looking at the same data from different perspectives (different joins, different keys, etc.), then the DB approach will start to shine. DB's are decathlon athletes, not specific event athletes. (BTW, Oracle is designing a RAM-only RDBMS I hear.)

Telephone switch programming is crazy with this technique for both data compression reasons and UI ease of use (you don't want to enter every single setting for every single phone number individually - you'd be at it for years).

I did not propose duplication. We would have to study the actual patterns to see what underlying structure and repetition pattern is really there. IMO, too many developers "see" trees where there is not really clean trees. Months or years later one often has to deal with refactoring a lot of code and other shuffling to compensate. I once had to build a special "3D rollup" accounts receivable turnaround tracking and reporting system. The structure looked like a classic roll-up tree at first, but I eventually gave up on the tree idea and found sets worked much better. I admit that it takes more training to get the users (accountants in this case) to understand sets, but lucky I had a smart user for that one. She picked it up in a snap. One is not always that lucky.

I will admit that for many humans trees are easier to grok, but they just don't reflect the messiness of the real world that well.

Besides, trees are graphs.

Yes, but the reverse is *not* true, and that is the problem. Sets are more general-purpose than trees. You can build trees with sets, but it is much trickier to build non-tree sets with trees. (Did I say that right?) IOW, sets can serve as trees much easier than trees can serve as sets. I say, go with the general-purpose tool rather than marry your design to trees.

No, its the other way around. You're writing the indirection on an ad hoc basis. The OO language compilers systematizes (if thats a word) the approach and hides the complexity leaving you with (hopefully) the essentials of your design minus the ugly dispatch tables that make it work. You're doing the same thing that they do, in a less efficient and manual manner. It amounts to preferring assembler over C.

I am sorry, but I just don't see this. Again, we would probably have to look at actual patterns of repetition and relationships to see what the ideal approach would be. Besides, the "trick" is to farm off the maintenance of such relationships to an operator or intern so that a programmer does not have to deal with actual data entry of such info. Being in tables we "inherit" off-the-shelf Db features like persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc etc etc. How is that for "automatic"?

I will agree that my approach may require a little extra "manual dispatch" programming that OO would take care of IF trees were the best sharing shape, but my approach also allows one to use more "juiced-up" dispatching techniques if needed, without major code overhauls. I have seen trees run out of gas at least twice. Even in the off chance repetition patterns stayed tree-shaped, they are still easier to sift and view as tables. The dispatching code only need be written once, but the data (including code references) has to be maintained for a long time. Still a bargain in my book.

It is the classic tradeoff between a dedicated niche tool versus a general purpose tool. TOP dispatching is more general purpose, and thus will be a bit more costlier if the need tends to be just one thing. If you only use the cork-screw in your swiss army knife, then you might as well just buy a cork-screw. But the world is usually not tree-shaped in my observation.

Thus, add juiced-up dispatching ability to persistence, joins, multi-user-handling, report writers, RAD screen builders, query languages, table browsers, etc. I am not going to give all those up to save 1 line of code per 500 lines.