On Oct 16, 2006, at 9:07 PM, Andy Dent wrote:
On 17/10/2006, at 6:44 AM, Norman Palardy wrote:
Many times normalizaton practices would dictate that you have a
possibly meaningless unique key.
Sometimes there is data that is unique per person that makes a
nice key (social insurance number, employee number, etc)
Just wanted to chip in here, as using SSN is a favourite American
trick.
1) it breaks when you have to deal with foreigners
2) it is often broken at data entry - whilst you can compel people
to enter an SSN you can't always compile them to enter a CORRECT one.
Highly recommended: "Database Design for Mere Mortals"
Agreed that SSN is only adequate for some applications.
If the system is for the collecting taxes from citizens of Cananda
SSN is probably a good key as all individual taxpayers are required
to have one and employers are required to see their records have it
and use those id's when they submit their records of taxes withheld
from pay cheques.
Getting the correct one is an entirely different matter and often
folsk spoof them to collect multiple unemployment cheques, etc.
But if you simply want to track all Canadians then it sucks because
not all Canadians have one (ie anyone not working might not have one)
and uniquely identifying each citizen is a different problem in this
case.
Of course knowing what a system is designed for and how you will use
it is always part of knowing how to design the system in total and
what you have available for candidate keys.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
