Re: User defined types -- Social Security number...

On Mon, Mar 01, 2004 at 09:42:48AM -0800, Steve Crawford wrote:
> I missed the start of this thread but will chime in with a comment 
> anyway.
> 
> My rule is to select an appropriate numeric type of data if you will 
> be doing numeric types of things to it, character types if you will 
> be doing character manipulations, etc.
> 
> I don't know of any good reasons to need to know SSN/6.9, sqrt(SSN), 
> SSN+7.86 but there are plenty of good reasons to need the first three 
> characters (the "area number"), the middle two characters (the "group  
> number", and the last 4 characters (the "serial number", often 
> (ab)used as a password for banking and other purposes).

Another excellent point.  I often store zip codes as text for this
reason.

The only other thing that I would mention is that if the SSN field in
the db will be a key of some sort, which is often the case, then it
might be more efficient to store it as an integer.  It might be more
efficient to store it as a character string.  The author should test
in this case to determine the most efficient way.

As for character vs. integer manipulations, in most scripting style
languages, which is pretty much exlusively what I use, there's no
need to think about types, and something like an SSN will silently
change between being character or integer depending on what operations
are being performed on it.

Michael
-- 
Michael Darrin Chaney
mdchaney@michaelchaney.com
http://www.michaelchaney.com/