Re: A general questio about names
From: Dan <dan_at_nospam.com>
Date: Mon, 12 Sep 2005 09:58:46 -0500
Message-ID: <GIgVe.8$bd3.42_at_news.uswest.net>
>
>
> 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
Date: Mon, 12 Sep 2005 09:58:46 -0500
Message-ID: <GIgVe.8$bd3.42_at_news.uswest.net>
On 9/10/2005 3:34 PM, 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
Calling Big Brother... Received on Mon Sep 12 2005 - 16:58:46 CEST