SQL Server 2005에서 전화 번호를 저장하려면 어떤 데이터 형식을 사용해야합니까?
전화 번호를 테이블에 저장해야합니다. 어떤 데이터 유형을 사용해야하나요? 기다림. 답장하기 전에 읽어주세요 ..
영업 담당자가 검색 (와일드 문자 검색 포함)에이 필드를 사용할 수 있으므로이 필드는 많이 인덱싱되어야합니다.
현재 전화 번호는 XML 파일에서 다양한 형식으로 제공 될 것으로 예상됩니다. 균일 한 형식으로 변환하려면 파서를 작성해야합니까? 수백만 개의 데이터 (중복 포함)가있을 수 있으며 일부 소스 데이터가 나올 때마다 서버 리소스 (너무 많은 전처리와 같은 활동에서)를 묶고 싶지 않습니다.
어떤 제안이라도 환영합니다 ..
업데이트 : 소스 데이터를 제어 할 수 없습니다. xml 파일의 구조가 표준입니다. xml 구문 분석을 최소로 유지하고 싶습니다. 일단 데이터베이스에 있으면 검색이 빨라야합니다. 여기에서 진행되는 한 가지 미친 제안은 Ajax AutoComplete 기능과 함께 작동해야한다는 것입니다 (따라서 영업 담당자가 일치하는 항목을 즉시 볼 수 있음). 세상에 !!
여기에는 다음이 포함됩니까?
- 국제 전화 번호?
- 확장?
- 실제 숫자 외에 다른 정보 (예 : "바비 요청")?
이 모든 것이 아니라면 10 자 필드를 사용하고 숫자가 아닌 모든 데이터를 제거합니다. 첫 번째가 예이고 다른 두 개가 아니요이면 두 개의 varchar (50) 필드를 사용합니다. 하나는 원래 입력에 사용하고 다른 하나는 숫자가 아닌 모든 데이터를 스트라이프하고 인덱싱에 사용합니다. 2 개 또는 3 개가 예라면 확장 또는 기타 데이터가 무엇인지 결정하고 적절하게 처리하기 위해 두 개의 필드와 일종의 미친 파서를 수행 할 것이라고 생각합니다. 물론 인덱스를 만들 때 여분의 문자를 제거하는 인덱스를 사용하여 두 번째 열을 피할 수 있지만 두 번째 열을 만들고 아마도 트리거로 문자 제거를 수행 할 것입니다.
업데이트 : AJAX 문제를 해결하기 위해 생각만큼 나쁘지 않을 수 있습니다. 이것이 현실적으로 테이블에 대해 수행되는 주요 방법 인 경우 내가 말한 것처럼 보조 열에 숫자 만 저장 한 다음 해당 열의 인덱스를 클러스터 된 열로 만듭니다.
우리는 varchar (15)를 사용하고 확실히 해당 필드에 대한 색인을 생성합니다.
그 이유는 국제 표준이 최대 15 자리를 지원할 수 있기 때문입니다.
국제 전화 번호를 지원하는 경우, 전화 번호 필드의 길이를 구문 분석하고 확인하여 미국으로 돌아가는 전화를 제한하지 않도록 쿼리를 더 잘 필터링하기 위해 World Zone Code 또는 Country Code를 별도로 저장하는 것이 좋습니다. 예
미국 전화 번호 만 저장하는 경우 CHAR (10)을 사용하십시오. 숫자를 제외한 모든 것을 제거하십시오.
나는 아마도 여기에서 명백한 것을 놓치고 있지만 가장 긴 예상 전화 번호에 대해 충분히 길지 않은 varchar가 잘 작동하지 않습니까?
나는 경우 입니다 분명 뭔가 빠진 사람이 그것을 지적한다면, 나는 그것을 사랑 해요 것 ...
varchar (22)를 사용합니다. 내선 번호가있는 북미 전화 번호를 담을 수있을만큼 큽니다. 모든 불쾌한 '(', ')', '-'문자를 제거하거나 모두 하나의 균일 한 형식으로 구문 분석 할 수 있습니다.
알렉스
SQL Server 2005는 인덱싱 된 varchar 필드의 텍스트에 대한 하위 문자열 쿼리에 매우 최적화되어 있습니다. 2005 년에는 인덱스 필드의 문자열 요약에 새로운 통계를 도입했습니다. 이는 전체 텍스트 검색에 크게 도움이됩니다.
varchar를 사용하는 것은 매우 비효율적입니다. money 유형을 사용하여 사용자 선언 유형 "phonenumber"를 만들고 양수 만 허용하는 규칙을 만듭니다.
(19,4)로 선언하면 4 자리 확장명을 저장할 수 있고 국제 전화 번호를 저장할 수있을만큼 커질 수 있으며 9 바이트의 저장 공간 만 차지합니다. 또한 인덱스가 빠릅니다.
nvarchar를 전처리하여 가능한 한 많이 표준화합니다. 확장을 추출하여 다른 필드에 저장하고 싶을 것입니다.
데이터를 정규화 한 다음 varchar로 저장합니다. 정규화는 까다로울 수 있습니다.
그것은 한 번의 히트 여야합니다. 그런 다음 새 레코드가 들어 오면이를 정규화 된 데이터와 비교합니다. 매우 빨라야합니다.
다양한 전화 번호 형식을 수용해야하므로 (확장자 등을 포함 할 수 있음) 다른 varchar처럼 처리하는 것이 가장 합리적 일 수 있습니다. 입력을 제어 할 수 있다면 데이터를 더 유용하게 만들기 위해 여러 가지 접근 방식을 취할 수 있지만 그렇게 들리지는 않습니다.
단순히 다른 문자열로 취급하기로 결정하면 잘못된 데이터, 신비한 전화 번호 형식 및 기타 팝업과 관련하여 불가피한 문제를 극복하는 데 집중할 수 있습니다. 문제는 데이터에 대한 좋은 검색 전략을 구축하는 것이지 내 의견으로는 데이터를 저장하는 방법이 아닙니다. 수집을 제어 할 수없는 대량의 데이터를 처리해야하는 것은 항상 어려운 작업입니다.
SSIS를 사용하여 정보를 추출하고 처리합니다. 이렇게하면 SQL Server에서 분리 된 XML 파일을 처리 할 수 있습니다. 필요한 경우 별도의 서버에서 SSIS 변환을 수행 할 수도 있습니다. VARCHAR을 사용하여 전화 번호를 표준 형식으로 저장합니다. NVARCHAR는 숫자와 '+', '', '(', ')'및 '-'와 같은 몇 가지 다른 문자에 대해 이야기하고 있기 때문에 불필요합니다.
varchar길이 제한이 있는 필드를 사용하십시오 .
확장자를 나타 내기 위해 "x"또는 "ext"를 사용하는 것이 일반적이므로 15 자 (전체 국제 지원을 위해), 3 ( "ext"), 4 (확장자 자체)를 허용하여 총 22자를 허용합니다. . 그것은 당신을 안전하게 지켜줄 것입니다.
또는 입력에 대해 정규화하여 "ext"가 "x"로 변환되어 최대 20 개를 제공합니다.
이 스레드가 오래되었다는 것을 알고 있지만 특히 .NET 프레임 워크에서 서식 지정을 위해 숫자 형식으로 저장하는 이점을 언급 할 가치가 있습니다.
IE
.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
전화 번호와 같은 다중 값 속성에 대해 별도의 테이블을 갖는 것이 항상 좋습니다.
소스 데이터를 제어 할 수 없기 때문에 XML 파일의 데이터를 구문 분석하고 적절한 형식으로 변환하여 특정 국가의 형식에 문제가 없도록 별도의 테이블에 저장하여 인덱싱 및 검색은 모두 효율적 입니다.
감사합니다.
'Programing' 카테고리의 다른 글
| 개행 문자를 제거하기 위해 bash 명령 대체를 피하는 방법은 무엇입니까? (0) | 2020.11.02 |
|---|---|
| Jenkins 로그인 시간 제한 늘리기 (0) | 2020.11.02 |
| Valgrind Massif 도구 출력 그래픽 인터페이스? (0) | 2020.11.02 |
| 클래스 인스턴스의 속성을 검증하는 올바른 접근 방식 (0) | 2020.11.02 |
| Git 병합되지 않은 경로 문제 (0) | 2020.11.02 |