Re: SQL Humor

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 - 19:34:44 CEST