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

Vadim Tropashko <vadimtro_at_yho.cm> wrote:

>VC wrote:

>> Would you be kind enough to provide more detail about the new dense
>> encoding schema ?

>Nested Intervals Model (http://www.dbazine.com/tropashko4.html) labeled
>each node with binary rational number, which is essentially a pair of
>integer numbers. Given that a set of all pairs of integer numbers can be
>enumerated, it easily follows that we can code each node with one
>integer only. This is not a very interesting idea, however. We save some
>storage, but for all practical querying purposes we would have to
>translate into binary rational numbers. Plus who cares about storage
>limitations nowadays?

>We'll explore a different approach. We employ a triangular navigation
>method which is similar to the enumeration mentioned in the previous
>paragraph, but we not refer to numerator and denominator values explicitly.

I just saw this. The problem was the sparse use of integers as your integer pairs exploded from binary shifting, correct? which as soon as the very idea of shifting enterred your mind you knew would be at least a potential overflow problem. This below avoids those geometric progressions?

I wonder, too, if there is a bias in favor of small lists, in any case, in a 'flattened' substitute for the adjacency model, which itself hides each subdirectory by the single local link, and is what Celko was attempting to 'flatten' out, correct, and what your method attempted to refine for the maintenance overhead of his method?

And I wonder, from that trop4 URL, that you suggest an 'adjacency list' is synonymous with a table of contents, or XML tree, or the like. That is, is the adjacency model still the description of any particular XML tree, say for example, even if that is stored as nested sets for purposes of rapid query and retrieval - assuming some custom '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. Received on Sun Nov 09 2003 - 13:08:46 CET