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.
>
> 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.

This is indeed a serious problem.

People are now discovering just how horrible a thing it is to use singular sorts of "universal identifiers" like SIN and SSN numbers.

There is certainly merit to having systematic ways to create identifiers that don't fall prey to common problems that people have too often fallen into.

GUIDs aka UUIDs also have both merits and demerits...

-- 
(reverse (concatenate 'string "moc.liamg" "_at_" "enworbbc"))
http://cbbrowne.com/info/
If we were meant to fly, we wouldn't keep losing our luggage.