Re: using path notation /../../.. for hierarchy

"Marshall Spight" <mspight_at_dnai.com> wrote in news:0sQEa.93901
> For example, no university or even high school that I know
> of offers diplomas based on a simple one-to-many relationship within their
> course catalog. (Although perhaps I have not understood you.)

In the case of this client, the tree was the exact right fitting structure (i.e. no classes are shared between modules/diploma's).

> I think they're going to like relations better.
> One big advantage of relations over what you're describing is the fact
> that there is a single uniform approach to data. All structural
information
> in a relation is encoded as data, and all data is data, and there is a
uniform
> way to query and update data. That means you have exactly one way
> to query and update both data and structure. In tree-oriented systems,
> there is one way to query and update structure and a different way to
> query and update data. That's more complicated, although perhaps
> more "intuitive."

I think above remark is true for real tree-oriented systems. But what I described is using a relational database where in one column the 'path' is encoded.
The big advantage, imho, is that you do not need recursive code and multiple queries to select a branch of the tree. Just use LIKE . So it's more of a encoding thing.

Modifying the tree, for example moving a branche to another node, can be expressed in one UPDATE query as well.
t Received on Mon Jun 09 2003 - 03:29:17 CDT