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

From: Dan <guntermann_at_verizon.net>
Date: 16 May 2006 19:31:29 -0700
Message-ID: <1147833089.114383.203000_at_j73g2000cwa.googlegroups.com>


"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.

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. 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. And how about domains where ordering rules/comparison operators are intended to be different than say, perhaps the standard ANSI collation? A same domain with a different ordering might have to be "redundantly" maintained?

  • Dan
Received on Wed May 17 2006 - 04:31:29 CEST

Original text of this message