Re: Trying to define Surrogates

Bob Badour wrote:
> erk wrote:
>
> > JOG wrote:
> >
> >>are you telling me that two Cans of Campbell's have no identity without
> >>an artificial label? If that were true you would not be able to
> >>distinguish them, yet you can. What, then, is that distinguishing
> >>property?
> >
> >
> > That's a deep philosophical issue for William Kent to answer, and one
> > which depends critically on formal definitions of "identity", "same",
> > "equivalent", "equality", "distinguish," etc. Whether you assign a
> > number (which may or may not be printed on the can), or an RFID, a
> > database has no way to distinguish them unless you give it that
> > artifical label. I agree the cans are distinct in the real world, and
> > have identity. It makes no real difference for most of the data we care
> > about. If I spill the pyramid of cans, and hand you an undented one,
> > will you be able to determine whether it's the one you were eyeballing
> > before I knocked them down? So when physical location changes, and you
> > don't track it explicitly, identity is lost - still there, but unknown
> > to us.
> >
> > A database is not the real world. Since a database concerns known
> > facts, the limits of our knowledge (e.g. whether you can know which of
> > the nearly-identical cans you want) are direcly reflected in our
> > ability to design and maintain a database.
>
> Not only the limits of our knowledge but the limits of our interest.

Yes, I forgot to mention that.

> Do we really care about the identity of individual cans of soup?

Normally not. Something ephemeral and similarly indistinguishable might be web site hits - while reading this newsgroup, for example, I usually generate several hits on the same URL, and they vary only by timestamp. We'd probably use a surrogate key, as timestamp isn't quite granular enough (I could probably write a short program to quickly produce several requests with identical timestamps), and there's no other natural key that suggests itself.

• erk