From: Michael Chaney <mdchaney@michaelchaney.com>
To: pgsql-sql@postgresql.org
Subject: Re: User defined types -- Social Security number...
Date: Mon, 1 Mar 2004 15:18:43 -0600
Message-ID: <20040301211843.GB19105@michaelchaney.com> (raw)
In-Reply-To: <200403010942.48760.scrawford@pinpointresearch.com>
References: <c16fu8$2ro4$1@news.hub.org>
<m37jy5ryto.fsf@wolfe.cbbrowne.com>
<Pine.LNX.4.58.0403011151340.17082@screamer.tcp-ip.info>
<200403010942.48760.scrawford@pinpointresearch.com>
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/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: mdchaney@michaelchaney.com
Subject: Re: User defined types -- Social Security number...
In-Reply-To: <20040301211843.GB19105@michaelchaney.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox