Re: Nested Sets vs. Nested Intervals
Date: 14 Nov 2005 10:52:56 -0800
Message-ID: <1131994376.176033.290540_at_g14g2000cwa.googlegroups.com>
asdf wrote:
> Yes, but my current infrastructure is that the fractions are stored in
> the same table as the category id. The book mentioned that I have to
> store the fractions on a seperate table. I use example 2 of the
> insertion example in http://arxiv.org/html/cs.DB/0401014 but it didn't
> work. How do I add a child node to the parent node correctory? How do I
> query the immediate children and insert a node after the oldest child
> with the fractions stored in the same rows? I wrote code that converts
> materialized path to fractions and vice versa, but how do I use it to
> insert new nodes?
Let's get back to the basics of an RDBMS. Your questions are all based on the wrong mental model. Rows are not records; fields are not columns; tables are not files. Edges are Not Nodes/Vertices! Just kidding. I indeed wrote that edges and nodes should be kept in separate tables. However, this has been written in chapter on graphs, not trees (the next chapter). If this were written for trees, please let me know the page number, as I have to correct it. The idea of tree encoding is that we add one or several more columns to the table of *nodes*.
OK, going back to farey fractions article. When saying that something is not working please be more specific, and tell what query/dml failed, and, more important, on what set of data. For example, make a tree with 3 nodes, and show that insertion of the 4th node fails.
There are 3 improvements that make migrating to the matrix encoding attractive:
1. Faster algorithm for finding next fraction. 2. An algorithm for moving subtrees. 3. Finding children via adjacency relation.I don't quite understand your reasons why you don't want to use matrix encoding. (Although, some developers are quick to dismiss the entire nested intervals because it allegedly requires to use stored procedures.) Received on Mon Nov 14 2005 - 19:52:56 CET