From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Data Base design pet peeve
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 29 Sep 1992 14:48:26 GMT

In article <66811@cup.portal.com> DonD@cup.portal.com (Don Robert DeCosta) writes:
...I wrote:
>>But one thing I don't understand in your example.  In what way is this
>>arbitrary number useful?  Why is it visible?  It doesn't have much bearing
>                           ^^^^^^^^^^^^^^^^^^
>
>*I* never said is was visible, discounting this whole "CPU-time used to
>prepare external format" argument.
>
>Now, come one! You know better than that!

Ok, I admit it.  Yes, I do know better than that.

> The key item has to be unique
>and YOU may think Stuart MacMartin is unique but I guarantee that as soon
>as *I* decide to use it as a key there'd be two of you!

And you may note that I didn't say it wasn't required.  I just said that
it shouldn't be visible.  I should have enough attributes that you can
find me.  At the video stores I go to, I use my phone number.

And you certainly shouldn't be using my name as a key, because I might
change my name.

Relationships between objects obviously have to be made using an object
identifier that does not rely on my attributes.  (If I changed my name
or company name, I don't want all the related info to be lost.)  But
if this field that the original poster mentioned is an object identifier,
what does that have to do with the real world?  It is an artifact of
needing something constant to identify an object.  Thus "Should it
be character or integer" should be entirely influenced by database
requirements, not "modelling the real world" requirements.  And if at
all possible, it should not be visible to anyone.

I like to be identified using attributes instead of a card, where this
is reasonable.  I certainly don't want to know my number (even if I do
have a perverse desire to know my drivers licence and VISA number).
I can, at the moment, be identified with my phone number or sjm@bnr.ca.
This may change, but why should I remember anything else?  (Ok, when
my phone number changes, I have to be able to find my entry based on
my previous attributes.  There had better be enough attributes to 
uniquely identify me should someone else get my phone number.)

I know this is a little off topic, but it is the cause of my rampage.
Cards should only be used where they speed up common transactions or
act as a security device.  My library has a card but the scanner brings
up my entry quickly; this saves typing my name or phone number, and
anyway, phone # is not good enough because our household has 3 cards.
But my grocery store uses a card that is thick enough that I've
considered changing stores over it!  In Ontario, every individual has
a health card number and a nice thick health card.  You are supposed
to carry it with you - and carry your children's cards too!  Oh, and
I have a drivers licence and a SIN, too. And a VISA card.
I don't have a Bay card because it is YACC (yet another credit card).
Why do I need all these numbers?  And why do I need all these cards?
The point is, where there is an object id VISIBLE TO ME I probably have
an associated card. I don't mind having different oids in different
databases: this makes it harder for independent databases to be linked.
But I don't really want to do business with you if you can't identify
me from my attributes (name, phone number, address, e-mail address).

> A good
>system would use some arbitrary customer_id and allow the clerk to search
>by your name to get to your records.

Agreed.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :