Re: TRM - Morbidity has set in, or not?
- From: J M Davitt <jdavitt@xxxxxxxxxx>
- Date: Wed, 17 May 2006 03:44:17 GMT
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
- Follow-Ups:
- Re: TRM - Morbidity has set in, or not?
- From: Dan
- Re: TRM - Morbidity has set in, or not?
- References:
- TRM - Morbidity has set in, or not?
- From: Frank Hamersley
- Re: TRM - Morbidity has set in, or not?
- From: Marshall Spight
- Re: TRM - Morbidity has set in, or not?
- From: J M Davitt
- Re: TRM - Morbidity has set in, or not?
- From: Marshall Spight
- Re: TRM - Morbidity has set in, or not?
- From: J M Davitt
- Re: TRM - Morbidity has set in, or not?
- From: Paul Mansour
- Re: TRM - Morbidity has set in, or not?
- From: J M Davitt
- Re: TRM - Morbidity has set in, or not?
- From: Dan
- TRM - Morbidity has set in, or not?
- Prev by Date: Re: TRM - Morbidity has set in, or not?
- Next by Date: Re: TRM - Morbidity has set in, or not?
- Previous by thread: Re: TRM - Morbidity has set in, or not?
- Next by thread: Re: TRM - Morbidity has set in, or not?
- Index(es):
Relevant Pages
|