Re: Units of Measurement in the Database Model

mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message news:<bdf69bdf.0204121340.3cd64e81_at_posting.google.com>...
> > Having defined the new type, you then just use it in the schema just
> > as you would use any other type.
> >
> > CREATE TABLE Stuff_Being_Measured (
> > Id SYSTEM_GENERATED_KEY PRIMARY KEY,
> > What Description NOT NULL,
> > When Time NOT NULL,
> > How_Much Measurement NOT NULL
> > );
>
> Would one ever want to combine heterogenous measurements into a single
> [user defined datatype] column? For example,

  I oversimplified.

   Instead of Measurement, use a label like 'Length'. The only valid units   for a length would be the ones that could be meaningfully converted from   one to another. Thus comparing Parsecs with Kilogram meters per second   squared would not be possible.

   Instead, we're talking about two types: Length (or distance) and Force.   The number of domains that the database can have is as extensive as you need.   This is exactly the same way that the application logic would deal with   the situation.

   But would I want to combine heterogenous measurements into a single   column? Yes, absolutely. As anyone who has read about the debacle of the   recent Mars probe will attest. In an enterprise information system with   global reach you had darn well better present your information to your   end users in terms they understand. The US is practically alone in clinging   to imperial measures of mass as a measure of commodities, for example. But   would you want a system that obliges US traders to whip out the calculator   to convert pounds of coffee (or tonness of steel) into kilograms (or   tons) every time they wanted to buy your product?

    What I have described here is more of a pattern than a complete solution.

    KR

            Pb Received on Sat Apr 13 2002 - 06:58:51 CEST