Re: domain questionnaire

From: JRStern <JRStern_at_gte.net>
Date: Wed, 21 Feb 2001 01:18:27 GMT
Message-ID: <3a931571.30087673_at_news.gte.net>


On Sat, 17 Feb 2001 02:00:40 GMT, vadim Tropashko <vadim_member_at_newsranger.com> wrote:
>I've just read C.J.Dates shots against some competetive technologies posted at
>http://www.firstsql.com/dbdebunk but feel that concept of domain also escapes
>rigid definition. In order to prove or falsify it, I compiled short list of
>questions and ask "Are those from the same domain?". Please post your opinions.
>1. coordinate x of a point in cartesian coordinates vs.
>angle theta in polar representation of point
>2. weight in lbs vs. weight in kgs

Is the domain a thing in the world, or is the domain an enumerable set of values in the representation? That, is the question.

Twenty years ago (and today?) Date and Codd wanted a database to be a transparent representation of things in the world, that was half the reason they each advocated rows to be identified by value, rather than by some "non-relational" arbitrary identifier, rowID, etc. Their "domains" were generally real-world domains.

It is not clear today if that was a good idea or not. It seemed to make the database more tractable mathematically, perhaps. But, the streets are now teeming with "certified" database architects who use an identity field or GUID as their primary key at all times, I am not aware of good support for enumerable domains in major databases (there are constraints and hand-coded triggers and referential integrity, but those are not necessarily the same things), and the world/representation issue remains unresolved.

OTOH, there are also hordes of OOP developers who believe that objects should be based on real-world entities, and yet, most OOP language implementations provide some kind of pointers and object identities, once again rather straddling the issue.

--

Did I answer the question?  My position is that domains in re
relational databases, are enumerable sets of values.  I would not
expect the database to equate measurements in different metrics --
certainly a single numeric field should be interpreted by a single
"semantic" domain, an enumerable set of values by a single metric,
either pounds of kilograms, either cartesian or polar.

Of course, application logic can sit on top of the data storage, and
the logic can be implemented as triggers or procedures or whatnot
within the database, in order to translate between domains and make
domain boundaries invisible to higher-level application components.

Joshua Stern
JRStern_at_gte.net
Received on Wed Feb 21 2001 - 02:18:27 CET

Original text of this message