Re: TRM - Morbidity has set in, or not?

Frank Hamersley wrote:
> J M Davitt wrote:
>

>> Paul Mansour wrote:
>>
>>> J M Davitt wrote regarding inverted indexes:

>>>> This has huge significance: all values in a date domain covering
>>>> hundreds of years require fewer than 100,000 values.  Time-of-day
>>>> precise to a second requires only 86,000 values.  Given these domains,
>>>> adding records to a system would require no new values -- the domains
>>>> can be established before the first data arrive
>>>
>>>

>> TRM, on the other hand, would maintain exactly one ordered set of
>> values for the domain and everything referencing the same date
>> would refer to the same value.  Indices aren't really needed.  Index
>> maintenance - the dreaded B-tree "rotate the root" operation - would
>> never occur.  Sure, as birth dates are corrected and licenses are
>> renewed, the value a given record refers to would change -- but the
>> values remain undisturbed and there's no need for index maintenance.

>> There is, of course, a trade-off: the record reconstruction table
>> has to be maintained.  That's significant work and the techniques for
>> doing it efficiently are, AFAIK, a closely-held secret.  (Not every-
>> thing's covered by the patent, you know.  When you apply for a patent,
>> you have to tell the world how you did it.  Some of the most
>> profitable industrial secrets are not patented.)

Date, at least, has written descriptions and examples of how this is done.

> Thinking aloud I am guessing for some queries eg. "this_date =
> that_date" you don't even have to refer to the "domain" elements because
> equivalence implies an identical physical "pointer" (a term of
> convenience, perhaps there is a better choice?). Similarly "this_date >
> that_date" can be abridged if the domain physical pointers themselves
> are ordered. Therefore if all the supported operations can be performed
> at the physical level then RR can be deferred to the last step of
> materialising the outcome.

Actually, if I understand the operations you're imagining, restrictions and selections (I'm distinguishing between these, here) both are more efficiently done in the "domain elements" rather than among the "physical pointers."

But, you know,...

> One question that pops up though - how do you represent a relation where
> no single attribute is a candidate key. eg. [Competitor;Date;Score]?

...I've probably taken this as far as I can without looking something up. There are a few documents available that describe TRM; they are a better place to look for the answers you seek than this forum is. Received on Tue May 16 2006 - 11:11:23 CEST