Re: Bags versus sets; are they needed?

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: 3 Apr 2002 23:54:36 -0800
Message-ID: <61c84197.0204032354.3170d557_at_posting.google.com>


"David Cressey" <david_at_dcressey.com> wrote in message news:<RFDq8.21$9g7.1778_at_petpeeve.ziplink.net>...
> > First Name Last Name Weight
> > ---------- --------- ------
> > Sam Jones 135.88
> > Kara Jones 135.88
> >
> > What is projection to <Last Name, Weight> is? Would it contain two
> > records or one? Does the answer depend upon precision?
>
> I think that issues of measurement and projection get very interesting
> indeed. I would suggest that when the original measurement is made of the
> weight, the weight as measured is a projection, made by the scales, from
> the actual weight to the measurement space. There are at least two sources
I agree. But the projection here is not related to the term projection in a DBMS-sense.
> of error in the scale, errors due to inaccuracy and errors due to lack of
> precision. Once the measure is stored in a computer, there is another
> projection that has taken place: the projection of the weight as measured
> onto the subset of the real numbers that the numeric datatype can represent.
>
There is an other potential for projection (in your term of the word) when the measured value is converted from the internal representation in the measurement device to the internal representation in the DBMS. Normally i would guess this to be a slightly theoretical consideration. I believe that most DBMS's will provide enough precision to store any physically measured item without loss. This opens up to a new discussion of how to store imprecise information in the first place: A big and somewhat scary subject (scary because those new "reals" loose normal behaviour and e.g. sometimes have to return "indeterminate" when they are compared).
> Any one of these projections can lose information. The lost information may
> or may not be of value to the originator of the query. Testing two real
> values for "equality" is always dicey. Look over any standard text on
> numerical analysis for a more complete treatment.

I agree. Floatingpoint values have an approximative nature and thus are generally not suitable as keyvalues. I doubt if the subject has been thoroughly discussed in the context of relational databases and projections.

Kind regards
Peter Received on Thu Apr 04 2002 - 09:54:36 CEST

Original text of this message