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

Hi,

Thanks for the response. I have a couple of follow-on questions.

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

Ok. Though understanding the alternative approaches to contrast to exhaustive enumeration would be useful, especially in light of the previous statement, "the values remain undisturbed and there's no need for index maintenance." Without enumeration, how does one claim that a set of values remain undisturbed?

2. "And CHAR (1000) is a trite example. How about JPEGs and MP3s and *.DOCs and XML."

Let's stick with the trite example and demonstrate the effectiveness of the trite example first. Isn't this just a restatement of the age old claim that serialization of everything is the solution to everything. Honestly, Claude Shannon covered this effectively and from an entirely theoretical perspective in the 60's.

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

This is an interesting and open question for me. It inevitably leads us back to whether domain and type are really the same thing. I tend to think not, and admittedly it runs against Date and many proponents here. An equivalent or equal domain can have different ordering operators in my opinion and considering symbolic values independent of some operators provides a greater degree of independence. But I digress.

You wrote earlier that "TRM, on the other hand, would maintain exactly one ordered set of values for the domain." If we refer to that same ordered set but want an alternative ordering, we run into the same problems that lack of physical independence provides in network, hierarchical, and odbms data models, except that the problem might become more extreme because of the massiveness of potential domains.

Don't get me wrong, I am not knocking the approach, but as with everything, it appears that this provides the set of benefit/shortcoming trade-offs that are dependent on context and on application that we've experienced before. It might not be a great "general" solution.

• Dan