Re: A general questio about names

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 Received on Sat Sep 10 2005 - 22:34:18 CEST