Re: using path notation /../../.. for hierarchy
Date: Mon, 9 Jun 2003 10:29:17 +0200
Message-ID: <3ee44561$0$36907$1b62eedf_at_news.wanadoo.nl>
"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 - 10:29:17 CEST
