Re: A general questio about names

John G. Eggert wrote:
> On 2005-09-10, -CELKO- <jcelko212_at_earthlink.net> wrote:
> > Vendors should have a verifiable tax id or Duns numbers. You want to
> > have an extrnal, verifiable id like the SIN -- and the law probalby
> > wants to you have it too :0
> >
> > Do not do a table of names; a name is an attribute and not an entity.
> >
>
> Joe:
>
> Thanks for the reply. I was a bit zonked out from work when I wrote the
> post. Indeed, a name is an attribute. It seems that some people advocate
> normalizing to the point where one would have an entity called first_name or
> some such and use this to generate queries of full names that would then be
> attributes of an entity such as employee. I view this as going overboard,
> but I'm not as well versed in the field as some.
>
> As for SSN (or SIN here in Canada), my wife's pregnancy is requireing a lot of
> use of my employee benefits package. I've had to give my SIN (the
> 'identification number' of the policy) to a number of people of questionable
> integrity. I suspect this is because the database uses my SIN as the primary
> key. This is a very bad thing. I'm not sure about the states, but in Canada
> there is legislation detailing who is entitled to know one's SIN. If they
> aren't entitled, the structure of the database shouldn't require it.
> (Canadian law explicitly allows one to refuse to provide a SIN unless it can
> be proved that it is required to comply with one of 18 specific laws and
> regulations or 7 specific programs). Any primary key would be needed for
> queries on the entity and hence made widely available. This leads me to the
> point of view that the SIN or SSN should NEVER be used as a primary key.
> Indeed, one should always question whether it is even needed in the context
> of the database. If it isn't needed, don't include it. If it is needed, make
> it 'hideable' so to speak.
>
> Cheers.
>
> JE

Whenever you need to hide the values of a primary key you can add a new column in your table which should at least satisfy the definition of the primary key.
Also, you need a good "device" for mass production of unique names. This adding of a "surrogate key" can solve some other more complex problems than hiding information.
I think your quetion is a very good one because nowadays there is more and more usage of personal information by companies (supermarkets, travel, medical, credit card companies, memberships, online puchasing...)

Vladimir Odrljin Received on Fri Sep 16 2005 - 00:02:22 CEST