Well, this is a fairly general problem that goes well beyond SSNs. In fact, the New York Times just ran an article about how the ubiquitous UPC codes that are used for identifying retail products are going to grow from the current 12 to either 13 or 14 digits in the next couple of years. Phone numbers, too: The typical U.S. 10-digit model is not enough for worldwide use, numbers with extensions, potential future growth, etc. U.S. zip codes used to be 5 digits and now are 9...

Personally I would *avoid* using a numeric field for a couple of reasons. For one thing, there's no guarantee that SSNs will always be numeric. The SSA could decide that making them a combination of letters and numbers provides more room for growth (or error checking, or whatever) without having to extend the field length. Also, using a numeric type means your code has to worry about things like management of leading zeros and overflowing the range of integers. Even though it's called a social security "number", I would tend to think of it as a social security "identifier".

Also, to get off on a bit of a tangent, cases exist even today where nine numeric digits is not enough. A decade ago I wrote a billing application used in doctors' offices and initially made the SSN = 9 digits assumption, only to discover that in medical records, there is often a convention of using an alphabetic suffix to distinguish between a man and a woman who are married, but only one of whom has a social security number. (For example, if the man is 123-45-6789 and has a wife without an SSN, her "SSN" entry had to be coded as 123-45-6789-B, if memory serves.) Yuck!