Re: Units of Measurement in the Database Model

From: Mikito Harakiri <mikharakiri_at_yahoo.com>
Date: 13 Apr 2002 11:03:12 -0700
Message-ID: <bdf69bdf.0204131003.3527c104_at_posting.google.com>


paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message news:<57da7b56.0204122058.6773d7da_at_posting.google.com>...
> 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.

To the point where the expence of creating and maintaining user-defined datatype is not quite obvious to the reader? Let summarise what a user needs to do in order to be able to store "pounds" and "kilogramms" together:

  1. Define a user defined type (with methods and operators).
  2. Define index(es) on the new type.
  3. Define statistics and histograms.
  4. Extend aggregate operators to embrace the new type.

(Didn't I forgot anything?-) And we compare this to a view with a trivial conversion factor?

A typical shotcut that DBMS would suggest to the user is defining just a single method that would map a value of user defined type into a number, so that most of the bullet 1, and all of 2,3, and 4 becomes unnecessary. But this mapping is esentially a conversion into standard units!  

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

Note, that some of the users, for example, physicists, might want to compare mass and length. Do you suggest different "LengthInMeters" classes for different categories of users?

> 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?

I don't see why measurements are different from other domains. In an enterprise system that spans the US and France with headquaters located in the US, do we store the names of the employees located in France in French? Received on Sat Apr 13 2002 - 20:03:12 CEST

Original text of this message