None of the data models I have designed included SSN number, so I havn't
participated in that round table debate to any degree of depth. However,
from what I have seen looking at systems that I have extended or maintained,
it seems that the method of implementing SSN has variations of VarChar to
Char. I've even seen cases where the length of SSN was inconsistent from one
table to another. Someone expressed concerns about the possibility of the
coding scheme changing, so I suggested a VarChar of 20. The reason I suggest
VarChar over BigInt is that the Fed could easily start adding alpha prefixes
or suffixes. Bad design considering it has been all numeric in the past, but
I would not put it past them. Doesn't matter that much about the actual
length; VarChar(20) with a 9 char code consumes the same disk storage as
VarChar(16). Conceptually, I would treat SSN in a manner similar to
LastName; it's just an identifier that has been 999999999 in the past, but
could change in the future.
"Gene Wirchenko" <genew_at_ucantrade.com.NOTHERE> wrote in message
news:ku4cg1l8brqndtlr348hvlvht1ocj3r5gc_at_4ax.com...
> On Fri, 19 Aug 2005 12:32:53 -0400, "JT" <someone_at_microsoft.com>
> wrote:
>
> [snip]
>
>>I make good use of check constraints, especially on user entered VarChar
>>columns. The reason I suggested VarChar(20) is to support in future
>>changes
>>the Fed may make to the SSN coding scheme.
>
> Why 20? Why not 30? Or 16?
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>
Received on Fri Aug 19 2005 - 12:34:44 CDT
