hi

> But if your tree is unlimited, there is other trick,

called 'table

> of relationship'. An additional table where all childs and grand-
> childs of a node are listed.
> Extracting of sub-trees in this case also simple and fast,
> especially for really big trees, when indices become quite
> selectable.

Can you clarify on that? I have the list of childs in my current
tree-like table (select id where parent = x)

How effective is providing the grandchildren information (if I have
say 10 levels)? All cases of grandchildrens can take tremendous
space and the problems of maintaining the structure also seem
nightmarish:

example: four levels, thirty nodes
1-+-3-+-5-+-7
| | | +-8
| | +-6-+-9
| | +-10
| +-4-+-11-+-13
| | +-14
| +-12-+-15
| +-16
2-+-17-+-19-+-21
| | +-22
| +-20-+-23
| +-24
+-18-+-25-+-27
| +-28
+-26-+-29
+-30

id, child, grandchild
1 3 5
1 3 6
1 4 11
1 4 12
2 17 19
2 17 20
2 18 25
2 18 26
...
29
30

so I in my example of binary tree (an optimistic one since I have
objects that group hundreds of other objects) - in my example this
would be 72 entries, each node appears in at least 2 places (once as
parent or grandchildren and once as children) with most of them
appearin the number of times equal to number of childrens times
number of grandchildren

my one million records table would have to be matched with few
millions entries of artificial index - question: is it worthwhile?

>
> SY, Dimitry Sibiryakov.

CUIN Kaczy