Skip site navigation (1) Skip section navigation (2)

Re: updating integer column

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>,Bruce Young <hbrucey(at)yahoo(dot)com>
Cc: PostgresPHP <pgsql-php(at)postgresql(dot)org>
Subject: Re: updating integer column
Date: 2003-02-24 19:27:04
Message-ID: 20030224192704.AF0D4103C2@polaris.pinpointresearch.com (view raw or flat)
Thread:
Lists: pgsql-php
> > oh and what is the best datatype to use for a 10 digit phone number?.
-snip-
> Secondly, for a phone number, ask yourself how you're going to treat it.
> Are you going to do a sum() across the numbers?  Or maybe multiply them
> together?
>
> If yes, then you should store them as some kind of numeric, int, or as a
> float.
>
> If, however, the numbers are not going to be used for math but for
> identification, then it is likely that a text / varchar type would be a
> better choice.

Don't use int:
create table foo (ph int);
insert into foo values (5105551212);
ERROR:  dtoi4: integer out of range

Use char(10). 

Better yet, "properly" normalize phone numbers into area-code (char(3)), 
prefix (char(3)) and number (char(4)) fields. This way you can error-check 
your phones against the area-code table, determine approximate geographical 
areas/time-zones, flag dangerous numbers (very high cost off-shore versions 
of 900/976 numbers that look like ordinary phone numbers), etc.

If you really want to you can even include a prefix table to do the same 
thing at the exchange level using NANPA data.

Even if you don't use a prefix table, updating your table when area-codes 
split will be easier if the ac and prefix are in their own fields.

It may be overkill for your app but for a variety of reasons is a requirement 
for ours.

Cheers,
Steve

In response to

Responses

pgsql-php by date

Next:From: scott.marloweDate: 2003-02-24 19:33:24
Subject: Re: updating integer column
Previous:From: scott.marloweDate: 2003-02-24 17:18:17
Subject: Re: updating integer column

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group