Re: Domain Definition

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

   This is the whole point of 'extensible' DBMS products (which most of them   are by now).

   The 'relational' data model that constitutes the framework of a SQL DBMS   (Hi Chris, Fabian!) doesn't care about the domains used to define relation   attributes. Each domain ought to have certain properties -- such as   equivalence to support functional dependencies -- but there is no requirement   that they be COBOL types -- INTEGER, VARCHAR etc -- at all. 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).

   All kinds of nice things follow when you do this, together with a few new   problems. Its a pity that the most common 'domains' kind of question   asked is of the 'Should I use a CHAR(12), or a VARCHAR(12), to hold salary   amounts?' form. :-( Received on Fri Jan 10 2003 - 00:28:13 CET