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

Paul Mansour wrote:

> J M Davitt wrote:
>
> "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. "
>
> But you still have to store the "everything referencing" stuff,
> correct? That's just not going to magically disappear. It seems to me
> that all of the advantage comes from having a column store over a
> row-store, and that the only way to get less data than a typical
> column-store would then be to compress a column with, say, run-length
> encoding. In other words, maintaining an ordered set of dates and
> having say, five columns referencing that ordered set does nothing for
> you over just maintaining five columns of dates if the you use a 32 bit
> int for storing the date and 32 bit int for storing the thing that
> references the date column. If the column in question were on a wide
> character domain then it would save space to have a integer to
> reference the column (of just make a new table and have foreign keys
> point to the values). So I guess my real question is what does TRM
> offer over a conventional column-store, which has been around for well
> over 30 years? I've read C.J. Date's small section in the 8th edition
> of text book on it, but I don't get it.

Paul, you seem to have missed the point that to keep the data ordered, you would have to store the date in the heap and in the index using a row store. With the column store, that is not required. So while the reference pointer is on the order of the size of the date, it only appears once.

With the index, the date appears at least twice. Once in the heap, and once in the leaf pages of the index. It may also appear elsewhere in the index. Received on Tue May 16 2006 - 03:05:13 CEST