Re: Domain Definition

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Thu, 9 Jan 2003 16:20:06 -0800
Message-ID: <qpoT9.23$L43.157_at_news.oracle.com>


"Paul G. Brown" <paul_geoffrey_brown_at_yahoo.com> wrote in message news:57da7b56.0301091528.4576b939_at_posting.google.com...
> 71062.1056_at_compuserve.com (--CELKO--) wrote in message
news:<c0d87ec0.0301090843.44cbc41a_at_posting.google.com>...
>
> > I would say semantics as a vital part of a domain. Consider
> > temperatures; it is not enough to say that the temperature is 25
> > degrees without giving the scale (Celsius?, Fahrenheit?, Kelvin?)
>
> Also Rankine (Fahrenheit adjusted to absolute zero: I implemented this
> once.)

Mixing units is bad idea anyway. This is why scientific community adopted standartization. If metric system is fixed, then there is no cofusion on the "semantics" of a given number.

Why do people agree that normalizing data schema is a good thing, while feel that requirement to store measurements in the same system is somehow too limited? Standartization just improves the quality of your data, similar to what normalization does!

> Modern DBMS
> products (including the open source ones like Postgres) are perfectly
capable
> of supporting a domain like 'temperature' to encapsulate unit and
measure
> (and error, if that's the semantic you'd like).

The domain idea looks like a kludgy attempt to fit the data into some unit system. It doesn't really care about the quality of the unit system.

In general, isn't the whole domain concept backward? People were manipulating quantities since the dark ages and generalized quantity idea as a number. The domain concept would never lifted them to grasp a simple idea that adding 3 apples and 3 oranges results in 6 fruits. Received on Fri Jan 10 2003 - 01:20:06 CET

Original text of this message