Re: matrix encoding IS adjacency list
Date: Tue, 20 Sep 2005 12:17:03 GMT
Message-ID: <35TXe.1608$q1.998_at_newsread3.news.atl.earthlink.net>
"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1127190484.053528.295470_at_f14g2000cwb.googlegroups.com...
> The materialized path approach and other approaches to handling
> trees in SQL are intellectually and academically interesting, but
> as practical techniques, they feel to me like they are working
> hard to compensate for shortcomings in the language. I suppose
> this is not a particularly original observation.
The materialized path approach, if I understand it right, is of practical interest in certain contexts.
The context I have in mind is the dimension table of a star schema, with a fixed depth tree, and intended to be used with some point and shoot interface, like PowerPlay or Business Objects. By materializing the path, you end up making all the ducks visible to a point and shoot operator (data analyst) who just wants to "drill down" to the bottom level, or aggregate to any level of the tree.
It's not intellectually powerful, but it sure is easy!
>
> The thing is, I haven't got a clear idea of what the alternatives
> are. Tree handling in OOPLs works fine, I suppose; at least it's
> less cumbersome that SQL. Many functional programmers are
> quite happy with using pattern matching and algebraic data
> types. This is certainly much better, but still doesn't feel
> like it has hit bedrock yet.
>
> Anyone have any candidates? Term rewriting languages? Rho
> calculus? Anything? I would love to have something that
> feels as solid for trees as the relational algebra does for
> relations.
>
Lisp??? (oops, I'm showing my age) Received on Tue Sep 20 2005 - 14:17:03 CEST