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

Dan 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. 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. "
>
> To work well, your statements would seem to imply the following:
>
> 1) For any declared domain, we must enumerate all possible values in
> advance.

Not necessarily. The examples cited are rather small domains - a couple centuries worth of dates, states, words used in names or addresses - and the supported system would undoubtedly benefit by having these known ahead of time. But exhaustive enumeration isn't the only way one can specify a domain.

> Suppose we were to do this with a fixed character string domain of say?
> CHAR(1000).
>
> If I understand what you are saying, then for that one fixed width
> domain, assuming 36 symbols for upper and lower case, etc., then we
> would need 2.006784635490209538403217829194e+1556 values stored, either
> in memory or on disk.

Well, you could do it that way if you wanted to -- but there are better ways to handle this. And CHAR (1000) is a trite example: how about JPEGs and MP3s and *.DOCs and XML? One needs to think in terms of "billions and billions" of bits when considering modern data stores.

   Granted, all domains of smaller symbol list
> widths could leverage the use of the largest set of possible values,
> but then there seems a price to pay for that little flag fixed width
> value consisting of 1 symbolic character that needs to pull its value
> from such a large store.
>
> When considering variable length domains, the problem gets a little
> larger and more complex.

Much larger, not more complex.

   And how about domains where ordering
> rules/comparison operators are intended to be different than say,
> perhaps the standard ANSI collation?

Every domain should provide an operator that allows users to distinguish different values. If ordering is necessary: supply it. (And yes, TRM requires ordering; whether it is the same operator exposed to users is a different question, but I don't see any need for them to differ.)

   A same domain with a different
> ordering might have to be "redundantly" maintained?

I don't understand this part.

>
> - Dan
>
Received on Wed May 17 2006 - 05:44:17 CEST