Hi Fernando!

Since around 1965, every person living in Norway has been given a unique 11-digit number at birth or immigration (abbreviated Fnr). The system for creating the number hasn't been changed since, and only in very rare cases (like getting a new identity for security reasons, changing gender or discovering that your birth date isn't registered correctly) can it be changed. The numbering system itself is likely to remain intact until 2054. Still, I hardly ever use it as a primary key (the exception being tables that are more or less temporary tables, or tables that I created quite a few years back).

Using a different number as a primary key is very simple, it only takes a few extra seconds to create such a field in new tables. Benefits include that the identity doesn't have to be stored in all tables (and people shouldn't have access to the Fnr unless they need it), it is possible to arrange for the Fnr not to be mandatory, and I it should be simpler to change a table from having the Fnr unique to allow duplicates (imagine your table of persons changing from containing one record per person to containing several records, changing the primary key can be time consuming if you e.g. have foreign keys referring to this table). And - if the retirement age changes - changing things may be simpler for me in 2054!

Another thing is that it generally fits in with me generally trying to avoid composite primary keys, though I admit this is simply because I get into the habit of creating a meaningless key for every table.

I'm sure there are other benefits as well, in general I'd say my reason for not using a Social Security number as a primary key is that using a surrogate key is at least equally simple and avoids hassles that could theoretically occur if the Social Security number was a primary key.

Hence, I recommend not using the Social Security number as a primary key of any new tables you create. Though I guess it may vary whether it is worth spending time modifying existing tables that already use the Social Security number as the primary key.

HTH,
Set

-----Original Message-----
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On Behalf Of Fernando Azevedo
Sent: 31. mars 2008 17:51

I can see it clearly now, it's a bad idea to show the user the PK. I
agree with the avoidance of using of a field with a significance as
data, although it's common to use Social Security number for PK, for
example. Would that be wrong also?