Re: More pain and sufferring with Tropashko's materialized path...

vadimtro_invalid_at_yahoo.com (Vadim Tropashko) wrote:

>Mark Johnson <102334.12_at_compuserve.com> wrote in message news:<ttasqvgjh5v48p40i6ebhkbpu9n81fg42u_at_4ax.com>...

>> least a potential overflow problem. This below avoids those geometric
>> progressions?

>For balanced trees yes. For unbalanced trees, for instance, tree
>degrading into a list,
>
>1
>1.1
>1.1.1
>1.1.1.1
>...

>it's still a problem. Note, that you have the same problem for
>materialized path encoding. If you String datatype length is limited
>to say 2000 characters, then you'll be unable to accomodate
>hierarchies deeper than 1000 levels.

I hadn't even considered that. But there are limitations to the size of string fields ('memo' fields would accomodate, but might not be consistently implemented to replace a string type in all cases).

>> 'parser'? I might well misunderstand. But I thought the adjacency
>> model wasn't based on the tree being a tree, but on how the tree was
>> represented in a table.

>I'm sorry, but I don't know what XML is, and have no idea why parsing
>is relevant.

I was referring to this from your trop4 article:

. . . same is true for every pair of adjoined records, then it is called adjacency list. If the opposite is true, . . .

I took that to mean that simply looking like a proper outline was sufficient to call it, as well, an adjacency list, whether or not a 'flattening' scheme was used or else where, as you say, a pointer is 'chased' up the line using recursive SQL. Did you simply mean the latter by the term - adjacency list? Received on Sun Nov 09 2003 - 22:38:34 CET