Re: The TransRelational Model: Performance Concerns

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:4194b815.8905203_at_news.wanadoo.es...
> On Fri, 12 Nov 2004 12:53:35 +0100, "Rene de Visser"
> <Rene_de_Visser_at_hotmail.de> wrote:
>

 that
> the implementation of the TRM tables don't use BTrees or hashing
> techniques

Wasn't the paper quite explicit that binary searches over binary relations were used in contrast to B*Trees? I did not see this validated exactly in that way in the patent, but I haven't read far enough.

The one thing that bothered me was the structure of reconstruction tables. The OP's analysis indicated that we can think of the relationship/linkage between attributes as binary relations. I think this confused me. I was thinking of a complete set of binary relations. Thus for a table of degree n, I was thinking there should be either n(n-1) or n(n-1)/2 relations depending on whether the binary relations had some reflexivity property.

This is obviously not the case after closer reading. But a linked, ordered reconstruction table bothers me. For relations of large degree, there seems to me to be a fixed overhead in traversing all attributes.

I was only able to read some of the patent application carefully, but I thought I read where it states that TRM "obviates" the need for hashing techniques.

, that a relation or a significant part of a 100000 tuples
> relation don't fit in main memory, he only considers the disk page
> loading costs, etc.
>
But he makes the same assumption with the conventional relational DBMS as well. This puts it on equal footing doesn't it?

> He also assumes that we need to make room for the inserts and the room
> is not already there.
>
If field value tables are really ordered domains, any new value in each one will require overhead to place the new value in the correct spot, no?

> Etc, etc.
>
> To only analize single relation queries is more than enough to
> discard the analisys.

I agree that I would have liked to see some multi-relation manipulation comparisons. I also saw some striking similarities to the concept of the index-organized table (IOT) in terms of strengths and weaknesses (this is simliar to Marshall's note on the inverted index).

I don't agree that focus a single aspect or problem is necessarily bad; but drawing a sweeping conclusion might be tough to base it on. Received on Fri Nov 12 2004 - 18:06:38 CET