SQL Server 2005에서 전화 번호를 저장하려면 어떤 데이터 형식을 사용해야합니까?


82

전화 번호를 테이블에 저장해야합니다. 어떤 데이터 유형을 사용해야하나요? 기다림. 답장하기 전에 읽어주세요 ..

영업 담당자가 검색 (와일드 문자 검색 포함)에이 필드를 사용할 수 있으므로이 필드는 많이 인덱싱되어야합니다.

현재 전화 번호는 XML 파일에서 다양한 형식으로 제공 될 것으로 예상됩니다. 균일 한 형식으로 변환하려면 파서를 작성해야합니까? 수백만 개의 데이터 (중복 포함)가있을 수 있으며 일부 소스 데이터가 들어올 때마다 서버 리소스 (너무 많은 전처리와 같은 활동에서)를 묶고 싶지 않습니다.

어떤 제안이라도 환영합니다 ..

업데이트 : 원본 데이터를 제어 할 수 없습니다. xml 파일의 구조가 표준입니다. xml 구문 분석을 최소로 유지하고 싶습니다. 일단 데이터베이스에 있으면 검색이 빨라야합니다. 여기에서 진행되는 한 가지 미친 제안은 Ajax AutoComplete 기능에서도 작동해야한다는 것입니다 (따라서 영업 담당자가 일치하는 항목을 즉시 볼 수 있음). 세상에 !!


소스 데이터의 파싱 / 정리 를 위해 github.com/googlei18n/libphonenumber 를 사용할 수 있습니다 .
Nicholas Hirras

답변:


58

여기에는 다음이 포함됩니까?

  • 국제 전화 번호?
  • 확장?
  • 실제 번호 이외의 다른 정보 (예 : "바비 요청")?

이 모든 것이 아니라면 10 자 필드를 사용하고 숫자가 아닌 모든 데이터를 제거합니다. 첫 번째가 예이고 다른 두 개가 아니요 인 경우 두 개의 varchar (50) 필드를 사용합니다. 하나는 원래 입력 용이고 다른 하나는 숫자가 아닌 모든 데이터가 스트라이프되고 인덱싱에 사용됩니다. 2 개 또는 3 개가 예라면 확장 또는 기타 데이터가 무엇인지 결정하고 적절하게 처리하기 위해 두 개의 필드와 일종의 미친 파서를 수행 할 것이라고 생각합니다. 물론 인덱스를 만들 때 여분의 문자를 제거하는 인덱스를 사용하여 두 번째 열을 피할 수 있지만 두 번째 열을 만들고 아마도 트리거로 문자 제거를 수행 할 것입니다.

업데이트 : AJAX 문제를 해결하기 위해 생각만큼 나쁘지 않을 수 있습니다. 이것이 현실적으로 테이블에 대한 모든 작업이 수행되는 주된 방법이라면 내가 말한 것처럼 보조 열에 숫자 만 저장 한 다음 해당 열의 인덱스를 클러스터 된 열로 만듭니다.


모든 질문에 예. 나는 소스 데이터에 대한 통제권이 없습니다. 거기에 좋은 제안이 있습니다. 감사.
John

12
순조 롭지 만 10 자 필드는 대부분의 영국 휴대폰 번호와 많은 영국 유선 번호를 포함하지 않습니다. 미국에서도 10 개 이상을 허용하여 향후 전화 번호 확장을 허용합니다.
Jon Egerton 2011-08-15

2
decimal(10,0)대신 char?
Mr Anderson

1
에 있기 때문에 @MrAnderson, 나는 그의를 생각하는 decimal(10,0)당신은 ... 당신이 그것을 필요로 할 때마다 숫자에 백업 패드 앞에 0을
Mathijs Flietstra

당신이 세상 어디에 있느냐에 따라 나는 브래드의 대답에 의해 강조된 것처럼 10자가 충분히 길지 않다고 생각 합니다.
Richardissimo

42

우리는 varchar (15)를 사용하고 확실히 해당 필드에 대한 색인을 생성합니다.

그 이유는 국제 표준이 최대 15 자리를 지원할 수 있기 때문입니다.

Wikipedia-전화 번호 형식

국제 전화 번호를 지원하는 경우, 전화 번호 필드의 길이를 구문 분석하고 확인하여 미국으로 돌아가는 전화를 제한하지 않도록 쿼리를 더 잘 필터링 할 수 있도록 World Zone Code 또는 Country Code를 별도로 저장하는 것이 좋습니다. 예


2
명백한 것을 간과 할 수 있지만 문자 데이터 유형을 사용하여 숫자 데이터를 저장하면 어떤 이점이 있습니까? 그리고 숫자 데이터 (예 : 구분 기호) 이상을 저장하는 경우 형식이 지정된 15 자리 숫자를 저장하는 데 15 자 이상이 필요하지 않습니까?
FtDRbwLXw6

13
@drrcknlsn 그 이유는 선행 제로입니다. 일부 (일부 국가에서 대부분)는 제로로 시작합니다.
Manse

15
@drrcknlsn 저는이 댓글이 2 년이라는 것을 알고 있지만 누군가가 귀하의 의견을 접하는 경우 : 일반적으로 수학적 계산을 수행하는 데 적합한 숫자 데이터를 저장하는 데 정수 데이터 유형을 사용해야하고 나머지는 사용해야한다는 것이 일반적입니다. 문자열입니다. 예를 들어 두 개의 전화 번호를 추가하거나 SIN / SSN 번호를 곱하는 것은 의미가 없으므로 문자열로 저장해야합니다.
Marco Pietro Cirillo

2
@drrcknlsn decimal(10,0)대신 왜 안돼 char?
Mr Anderson

@Mr A : 전화 번호의 길이가 지역 / 국가에 따라 다를 수 있기 때문일 수 있습니다. 선행 0으로 채우면 추가 구문 분석 문제가 발생합니다.
Trunk


3

나는 아마도 여기에서 명백한 것을 놓치고 있지만, 가장 긴 예상 전화 번호에 대해 충분히 길지 않은 varchar가 잘 작동하지 않습니까?

나는 경우 입니다 분명 뭔가 빠진 사람이 그것을 지적한다면, 나는 그것을 사랑 해요 것 ...


3

varchar (22)를 사용합니다. 내선 번호가있는 북미 전화 번호를 담을 수있을만큼 큽니다. 모든 불쾌한 '(', ')', '-'문자를 제거하거나 모두 하나의 균일 한 형식으로 구문 분석 할 수 있습니다.

알렉스


2

SQL Server 2005는 인덱싱 된 varchar 필드의 텍스트에 대한 하위 문자열 쿼리에 매우 최적화되어 있습니다. 2005 년에는 인덱스 필드의 문자열 요약에 새로운 통계를 도입했습니다. 이는 전체 텍스트 검색에 크게 도움이됩니다.


2

varchar를 사용하는 것은 매우 비효율적입니다. money 유형을 사용하여 사용자 선언 유형 "phonenumber"를 만들고 양수 만 허용하는 규칙을 만듭니다.

(19,4)로 선언하면 4 자리 확장명을 저장할 수 있고 국제 전화 번호를 저장할 수있을만큼 커질 수 있으며 9 바이트 만 저장됩니다. 또한 인덱스가 빠릅니다.


2
감사합니다. -1. Ingorance and not reading-waht abuot % 233 %-full table scan + conversions? 이것은 표준 문제이며 표준 솔루션이 있으며 숫자가 아닙니다. 모든 서식, btw를 제거합니다.
TomTom

@TomTom 내가 동의하는 money것은 대답이 아니지만 부분 문자열로 검색하는 것이 필요하지 않은 경우 (많은 사람들이 전화 번호의 일부를 기반으로 레코드를 조회 할 필요가 없다고 생각합니다), 사용하는 것이 잘못된 것은 무엇 decimal(10,0)입니까?
Mr Anderson

1

nvarchar를 전처리하여 가능한 한 많이 표준화합니다. 확장을 추출하여 다른 필드에 저장할 수 있습니다.


1

데이터를 정규화 한 다음 varchar로 저장합니다. 정규화는 까다로울 수 있습니다.

그것은 한 번의 히트 여야합니다. 그런 다음 새 레코드가 들어 오면이를 정규화 된 데이터와 비교합니다. 매우 빨라야합니다.


1

다양한 전화 번호 형식을 수용해야하기 때문에 (확장자 등을 포함 할 수 있음) 다른 varchar처럼 처리하는 것이 가장 합리적 일 수 있습니다. 입력을 제어 할 수 있다면 데이터를 더 유용하게 만들기 위해 여러 가지 접근 방식을 취할 수 있지만 그렇게 들리지는 않습니다.

단순히 다른 문자열로 취급하기로 결정하면 잘못된 데이터, 신비한 전화 번호 형식 및 기타 팝업과 관련된 불가피한 문제를 극복하는 데 집중할 수 있습니다. 문제는 데이터를 저장하는 방법이 아니라 데이터에 대한 좋은 검색 전략을 구축하는 것입니다. 수집을 제어 할 수없는 대량의 데이터를 처리해야하는 것은 항상 어려운 작업입니다.


1

SSIS를 사용하여 정보를 추출하고 처리합니다. 이렇게하면 SQL Server에서 분리 된 XML 파일을 처리 할 수 ​​있습니다. 필요한 경우 별도의 서버에서 SSIS 변환을 수행 할 수도 있습니다. VARCHAR을 사용하여 전화 번호를 표준 형식으로 저장합니다. NVARCHAR은 숫자와 '+', '', '(', ')'및 '-'와 같은 몇 가지 다른 문자에 대해 이야기하고 있으므로 불필요합니다.


1

varchar길이 제한이 있는 필드를 사용하십시오 .


1

확장자를 나타 내기 위해 "x"또는 "ext"를 사용하는 것이 일반적이므로 15 자 (완전한 국제 지원을 위해), 3 ( "ext"의 경우), 4 (확장자 자체의 경우)를 허용하여 총 22 자입니다. . 그것은 당신을 안전하게 지켜줄 것입니다.

또는 입력에 대해 정규화하여 "ext"가 "x"로 변환되어 최대 20 개를 제공합니다.


1

전화 번호와 같은 다중 값 속성에 대해 별도의 테이블을 만드는 것이 항상 좋습니다.

소스 데이터를 제어 할 수 없기 때문에 XML 파일의 데이터를 구문 분석하고 적절한 형식으로 변환하여 특정 국가의 형식에 문제가 없도록 별도의 테이블에 저장하여 인덱싱 및 검색은 모두 효율적 입니다.

감사합니다.


질문에 완전히 대답하지 않습니다.
Smart Manoj

1

이 스레드가 오래되었다는 것을 알고 있지만 특히 .NET 프레임 워크에서 서식 지정을 위해 숫자 형식으로 저장하는 이점을 언급 할 가치가 있습니다.

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string


0

대신 long 데이터 유형을 사용하십시오. -32,768에서 32,767 사이의 정수만 허용하므로 int를 사용하지 마십시오. 그러나 long 데이터 유형을 사용하는 경우 -2,147,483,648에서 2,147,483,647 사이의 숫자를 삽입 할 수 있습니다.


1
이것은 괜찮지 만 일부 숫자는 국가 코드로 시작하므로 국가 코드로 국제 번호를 저장할 수 없습니다. 예 : 0094777123123, 정규식 유효성 검사와 함께 varchar (15) 필드를 사용하는 것이 좋습니다.
Bubashan_kushan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.