Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
T-SQL (SS2K8)
»
format for phone number
12 posts, Page 1 of 2
1
2
»»
format for phone number
Rate Topic
Display Mode
Topic Options
Author
Message
harri.reddy
harri.reddy
Posted Wednesday, August 29, 2012 9:32 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Thursday, February 21, 2013 12:01 PM
Points: 149,
Visits: 346
hi
i need to craete table which has phone number field,
format (345) 234 - 2345
what is the best data type i can use,int,varchar.
plz suggest me
Post #1351709
Luis Cazares
Luis Cazares
Posted Wednesday, August 29, 2012 9:43 AM
SSC Eights!
Group: General Forum Members
Last Login: 2 days ago @ 3:26 PM
Points: 958,
Visits: 1,917
It should be char or varchar.
Ideally you should only store the digits and format the phone in the front end. However, you'll need an extra field for extension if needed.
Luis C.
Please don't trust me, test the solutions I give you before using them.
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1351728
ChrisM@Work
ChrisM@Work
Posted Wednesday, August 29, 2012 9:44 AM
SSCertifiable
Group: General Forum Members
Last Login: 2 days ago @ 8:21 AM
Points: 5,602,
Visits: 10,950
Numeric datatypes are inappropriate because telephone numbers may have embedded spaces, non-numeric characters and leading zero's. Length isn't constant either, so most folks use VARCHAR.
“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.”
- Gail Shaw
For fast, accurate and documented assistance in answering your questions, please read
this article
.
Understanding and using APPLY, (I)
and
(II)
Paul White
Hidden RBAR: Triangular Joins
/
The "Numbers" or "Tally" Table: What it is and how it replaces a loop
Jeff Moden
Exploring Recursive CTEs by Example
Dwain Camps
Post #1351729
Phil Parkin
Phil Parkin
Posted Wednesday, August 29, 2012 10:31 AM
SSCarpal Tunnel
Group: General Forum Members
Last Login: 2 days ago @ 5:12 AM
Points: 4,226,
Visits: 9,458
Luis Cazares (8/29/2012)
It should be char or varchar.
Ideally you should only store the digits and format the phone in the front end. However, you'll need an extra field for extension if needed.
I can imagine international numbers introducing difficulties to this solution (different display formats, therefore need to parse the country code first in a separate column etc etc).
I'd stick with varchar & use suitable constraints and front-end validation to stop rubbish getting in there.
____________________________________________________________________________________________
Help us to help you. For better, quicker and more focused answers to your questions, consider following the advice in this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
If you are asking for help and your post does not contain a question, you should expect responses which do not contain any answers. Put a question mark in there somewhere - it's not rocket science.
Post #1351761
Scott D. Jacobson
Scott D. Jacobson
Posted Wednesday, August 29, 2012 12:01 PM
Old Hand
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 5:17 PM
Points: 335,
Visits: 841
Luis Cazares (8/29/2012)
It should be char or varchar.
Ideally you should only store the digits and format the phone in the front end. However, you'll need an extra field for extension if needed.
This. Believe me, you will be much happier writing code going forward when all you have to deal with is xxxxxxxxxx.
Post #1351803
Luis Cazares
Luis Cazares
Posted Wednesday, August 29, 2012 12:14 PM
SSC Eights!
Group: General Forum Members
Last Login: 2 days ago @ 3:26 PM
Points: 958,
Visits: 1,917
Phil Parkin (8/29/2012)
Luis Cazares (8/29/2012)
It should be char or varchar.
Ideally you should only store the digits and format the phone in the front end. However, you'll need an extra field for extension if needed.
I can imagine international numbers introducing difficulties to this solution (different display formats, therefore need to parse the country code first in a separate column etc etc).
I'd stick with varchar & use suitable constraints and front-end validation to stop rubbish getting in there.
Display format should be defined for each user, not each phone. If managing international numbers, there should be a column designed for it. I'll prefer to store just the digits and probably in separate fields (according to the different attributes) to allow easy formatting. For me a phone number could be a composite attribute or even an entity, however it can be handled as a simple attribute.
Luis C.
Please don't trust me, test the solutions I give you before using them.
Forum Etiquette: How to post data/code on a forum to get the best help
Post #1351817
CELKO
CELKO
Posted Wednesday, August 29, 2012 12:34 PM
SSCommitted
Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945,
Visits: 2,782
some_phone_nbr CHAR(11) NOT NULL
CHECK (some_phone_nbr LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')
The standard for phone number formatting is set by the International Telecommunication Union in [E.123] and [E.164] (see the references below). The standards documents are available for a fee from the ITU [available at no charge since 2010 --Bob.] . A summary is available in the Google (UseNet) discussion group, titled Need ITU-T E.123 summary.
In short, a North American telephone number should look like:
+C-AAA-PPP-NNNN;ext=xxxx
“+” shows where the dialing prefix goes. This is one of either the International Direct Dialing (IDD) prefix (for Canada this is “011″ for overseas dialing) or the National Direct Dialing (NDD) prefix (“1″ for calls within North America, omitted for toll-free calls),
“C” is the Country Code (North America’s CC is “1″, and it is omitted for dialing within North America),
“AAA” is the area code (always required for dialing in Kitchener, Toronto, and other jurisdictions),
“PPP” is the Exchange (or Private Branch Exchange “PBX”; look in the phone book to see which exchanges are supported),
“NNNN” is the local portion of the number,
Note that the sequence “AAA-PPP-NNNN” is called a “local number” and “+C-AAA-PPP-NNNN” is called a “global number”. The “-” (hyphen) is a visual separator, as are “.” (period) , “(” (left bracket) and “)” (right bracket), which dialing applications should ignore.
Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1351832
CapnHector
CapnHector
Posted Wednesday, August 29, 2012 6:43 PM
SSC Eights!
Group: General Forum Members
Last Login: 2 days ago @ 10:07 AM
Points: 935,
Visits: 1,709
In my shop we store the 10 digit us number as a VARCHAR(16) (to allow for international numbers) but do not store any country code information or formating with the phone number (xxxxxxxxxx). we look up the country code based on other information in the database.
For faster help in answering any problems Please read
How to post data/code on a forum to get the best help - Jeff Moden
for the best way to ask your question.
For performance Issues see how we like them posted here:
How to Post Performance Problems - Gail Shaw
Need to Split some strings?
Jeff Moden's DelimitedSplit8K
Jeff Moden's
Cross tab and Pivots Part 1
Jeff Moden's
Cross tab and Pivots Part 2
Jeremy Oursler
Post #1351970
Jeff Moden
Jeff Moden
Posted Wednesday, August 29, 2012 11:16 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 8:21 PM
Points: 32,893,
Visits: 26,765
harri.reddy (8/29/2012)
hi
i need to craete table which has phone number field,
format (345) 234 - 2345
what is the best data type i can use,int,varchar.
plz suggest me
I have to chime in with several of the others. Don't store formatted telephone numbers in the database. Do the formatting in the front end if you have one.
A better thing to do would be to break the phone number up into pieces for Area Code, Exchange, and Line Number. Of course, international numbers will require country code (1-3 digits), city code (0 to 4 digits), and line number (1 to 6 digits, IIRC). Well, except for Mexico which uses country code, band, and some other stuff.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1352006
demonfox
demonfox
Posted Wednesday, August 29, 2012 11:55 PM
Ten Centuries
Group: General Forum Members
Last Login: Yesterday @ 6:46 PM
Points: 1,074,
Visits: 1,076
Use varchar . and don't save the formatted data in the database.
I had faced this issue , and it was a hell of a mess when a new company was acquired and we started using the data of their end. Format of phone number may differ based on the area or region or company, and you might loose flexibility.
why varchar ? I think it's better to do string operations on varchar in sql.
~ demonfox
___________________________________________________________________
Wondering what I would do next , when I am done with this one
Post #1352015
« Prev Topic
|
Next Topic »
12 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.