우편 번호를 데이터베이스에 저장해야합니다. 기둥은 얼마나 커야합니까?

103

내 Oracle 데이터베이스에서 열이 VARCHAR2가 될 것으로 예상합니다.

미국 우편 번호는 9입니다.

캐나다는 7입니다.

32 자 정도면 적당 할 것 같아요

내가 무엇을 놓치고 있습니까?

[편집] TIL : 12는 기여해 주신 모든 분들께 감사드립니다.

— EvilTeach
소스

유용한 링크이지만 정확도가 약간 다를 수 있습니다. 예를 들어 호주 우편 번호는 실제로 4 자리 인 경우 7 자로 표시됩니다. 참조 : en.wikipedia.org/wiki/Postcodes_in_Australia 및 www1.auspost.com.au/postcodes 에서 사용할 수있는 우편 번호 목록 .

— rossp

re : 내 이전 의견-이 목록이 가이드로 유용하지 않다는 의미는 아닙니다. 목록이 긴 우편 번호쪽에 오류가 있다고 가정하면 가장 긴 길이는 9 자이므로 16 자 이상이면 숨을 쉴 수있는 충분한 공간을 확보 할 수 있습니다.

— rossp

또한 국가 목록이 약간 짧습니다. 나는 확실히 나열되지 않은 행성에 더 많은 국가가있을거야 ...

— 로버트 Koritnik

2

en.wikipedia.org/wiki/List_of_postal_codes 에 따르면 '-'를 저장하는 경우 가장 긴 문자는 12 자이고, 그렇지 않으면 11

— Neil McGuigan

@CMS : 이 wikipedia 페이지에 대한 링크를 업데이트하고 싶을 수 있습니다 .

— Vajk Hermecz 2015 년

51

Wikipedia의 우편 번호 페이지를 훑어 보면 32 자 이상이면 충분합니다. 16 자라도 좋다고 말하고 싶습니다.

— Strager
소스

8

좋은 링크. US ZIP + 4의 구두점을 허용하더라도 내가 알 수있는 한 모든 국가에서 10 자이면 충분합니다.

— Jonathan Leffler

이 링크를 기반으로, 위의 링크 된 페이지에서, 나는 칠레 같은 나라를 수용하기 위해 18 갈 것 : en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

칠레는 7 자입니다. 참조한 웹 페이지는 단순히 구두점 변형을 보여줍니다.

— EvilTeach

21

@ neil-mcguigan이 이미 제기했듯이 wikipedia에는 주제에 대한 적절한 페이지가 있습니다. 12 개의 문자를 기반으로해야합니다 : http://en.wikipedia.org/wiki/List_of_postal_codes

위키피디아 기사에는 UPU (Universal Postal Union) 에 대해 꽤 좋은 ~ 254 개국이 나열되어 있으며 192 개 회원국이 있습니다.

— Vajk Hermecz
소스

2

Montserrat는 8 자이며 1110-1350은 범위를 나타냅니다. discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Malta의 유사한 우편 번호는 "AAA NNNN"과 같은 일반적인 우편 번호를 가지고 있기 때문에 Wikipedia는 편집이 필요할 수 있습니다. 열 길이를 조정해야하고 데이터 유형을 올바르게 사용해야한다면 나중에 문제가 덜 될 수 있기 때문에 15 자라도 괜찮습니다. 어쨌든 15 자 모두를 사용해서는 안됩니다 (varchar 또는 nvarchar 등?). .

— Manohar Reddy Poreddy

12

저장하려는 실제 데이터보다 큰 필드 크기를 선언하는 이유는 무엇입니까?

애플리케이션의 초기 버전이 미국 및 캐나다 주소를 지원할 경우 (질문에서 해당 크기를 호출한다는 사실에서 추론하고 있음) 필드를 VARCHAR2 (9) (또는 VARCHAR2 ()로 선언합니다. 10) ZIP + 4 필드에 하이픈을 저장하려는 경우). 다른 국가의 우편 번호에 대해 다른 사람들이 작성한 게시물을 살펴 보더라도 VARCHAR2 (9) 또는 VARCHAR2 (10)는 다른 모든 국가는 아니지만 대부분의 경우 충분합니다.

줄 아래에서는 필요에 따라 항상 열을 변경하여 길이를 늘릴 수 있습니다. 그러나 일반적으로 누군가가 어딘가에서 "창의적"이라고 결정하고 VARCHAR2 (50) 필드에 50 개의 문자를 넣는 것을 막는 것은 어렵습니다 (즉, 배송 레이블에 다른 줄을 원하기 때문입니다). 또한 경계 케이스 테스트를 처리해야합니다 (ZIP을 표시하는 모든 애플리케이션이 50자를 처리합니까?). 그리고 클라이언트가 데이터베이스에서 데이터를 검색 할 때 일반적으로 주어진 행의 실제 길이가 아니라 가져올 데이터의 최대 크기를 기준으로 메모리를 할당합니다. 이 특정 경우에 큰 문제는 아니지만 일부 상황에서는 행당 40 바이트가 적절한 RAM 청크가 될 수 있습니다.

제쳐두고, (적어도 미국 주소의 경우) 우편 번호와 +4 확장자를 별도로 저장하는 것도 고려할 수 있습니다. 일반적으로 지역별로 보고서를 생성 할 수있는 것이 유용하며, +4 확장자로 분류하지 않고 모든 것을 우편 번호에 함께 넣는 것이 좋습니다. 이 시점에서 우편 번호의 처음 5 개 문자를 SUBSTR하지 않아도되는 것이 유용합니다.

— 저스틴 케이브
소스

4

글쎄요, 우리가 Pro * C와 같은 어리석은 것으로 코딩한다고 가정하면, 필드가 성장할만큼 충분히 크다는 것은 사용량이 증가하더라도 코드를 건드릴 필요가 없다는 것을 의미합니다.

— EvilTeach

예, 미국 우편 번호를 5 자리와 4 자리 숫자로 나누면 사용 계획에 따라 의미가 있습니다. 예를 들어, 어떤 종류의 주소 일치를 수행하는 경우 먼저 zip5에서 일치하고 zip 9로 모호한 상황을 해결하고 싶을 수 있습니다. 국가 코드를 사용하는 것도 도움이됩니다

— EvilTeach

3

당신이 놓친 것은 우편 번호가 특별히 처리되어야하는 이유입니다.

우편 번호 로 작업 할 필요가 없다면 걱정하지 않는 것이 좋습니다. 작업이란 주소 라벨 등을 인쇄하는 데 사용하는 것보다 특수 처리를하는 것입니다.

VARCHAR2 (50) [예]의 3 개 또는 4 개의 주소 필드를 만들고 사용자가 원하는대로 입력하도록합니다.

당신이 정말로 필요로 주문 또는 거래 우편 번호로 그룹에? 나라마다이 분야에 대해 매우 다른 계획을 가지고 있기 때문에 그렇게 생각하지 않습니다.

— 팍스 디아블로
소스

나는 동의한다. VARCHAR2 필드를 사용하면 실제로는 우편 번호와 같은 필드가 실제로 중요하지 않습니다. 고객이 세부 정보를 입력 할 수 없기 때문에 성가신 고객보다 약간 큰 것이 좋습니다.

— Toby Allen

그리고 varchar는 데이터베이스 (최소한 DB2)가 스토리지 공간을 낭비하지 않도록 스토리지를 최적화 할 수 있기 때문에 편리합니다.

— paxdiablo

1

국가 및 우편 번호별로 분류하면 일부 지역에서는 우편 요금이 저렴하다는 점을 지적 할 수 있습니다.

— EvilTeach

10

Disgaree. 언젠가는 데이터베이스의 주소를 확인해야한다고 결정하게되며 (예 : 인쇄 및 데이터 입력 오류 수정) 모든 것을 넣는 것이 아니라 데이터 모델을 적절하게 구성하는 이점을 찾을 수 있습니다. 버킷.

— Gary Myers

1

@Pax 우편 번호 본부 (첫 글자 / 2 글자)로 미리 분류 된 로열 메일로 대량 메일을 건네 주면 일반 2 종 우편보다 저렴한 MailSort로 배송받을 수 있습니다. 그것은 하나의 예일뿐입니다.

— Richard Gadsden

3

표준화? 우편 번호는 두 번 이상 사용될 수 있으며 거리 이름 또는 도시 이름과 관련 될 수 있습니다. 별도의 테이블.

— 스테판 에거 몬트
소스

흥미 롭군. 다른 관점은 이유없이 단순히 반대표를 던졌습니다. +1

— EvilTeach

우편 번호는 일반적으로 도로 한쪽에있는 블록을 참조합니다. 더 넓은 지역을 찾으려면 우편 번호의 앞부분을 선택합니다. 이 정보를 별도의 테이블에 두는 것은 실제로 도움이되지 않으며 유지 관리가 더 복잡합니다.

— RevNoah

4

@EvilTeach : 주제를 벗어 났기 때문에 반대 투표를 받았을 것입니다. 전 세계에서 가능한 모든 우편 번호를 저장하기 위해 열의 크기를 알려주나요? 호

— 에서 Wmax

2

캐나다 우편 번호는 문자 및 숫자 (LNLNLN) 형식으로 된 6 자입니다.

— 테그 바인
소스

3

캐나다 우편 번호 중간에 공백이 있습니다. "ANA NAN"즉, 7 자입니다.

— EvilTeach

1

그러나 공간은 항상 중간에 있으므로 보관할 필요가 없습니다.

— Graeme Perrow

1

공백은 데이터의 일부가 아닌 것 같습니다. "참고 : 캐나다 우편 번호는 항상 알파벳 문자 / 숫자 / 알파 / 숫자 / 알파 / 숫자 (예 : K1A0B1)와 같은 순서로 형식이 지정됩니다." 그것은 Canada Post 웹 사이트에서 가져온 것입니다.

— tegbains

2

공간을 생략하는 것이 '정규화'와 관련이 있다고 생각하지 않습니다. 디스플레이 문제 일뿐입니다. 계좌 번호의 대시와 같습니다. 나는 그것을 저장하지 않을 것이며, 색인화 될 수있는 CountryCode (int) 필드보다 우선적으로 캐나다 우편 번호를 식별하는 데 의존하지 않을 것입니다. 데이터와 프리젠 테이션 레이어를 분리하는 것이 올바른 방법입니다.

— Sam

2

Canada Post는 봉투 주소를 지정할 때 우편 번호의 공백을 선호합니다. 공간과 함께 저장하고 진입시 유효성 검사를 처리하는 것이 가장 좋습니다.

— RevNoah

2

영국은 표준을 발표했습니다 : 영국 정부 데이터 표준 카탈로그

Max 35 characters per line

국제 우편 주소 :

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

영국 우편 번호 길이는 다음과 같습니다.

Minimum 6 and Maximum 8 characters

— PodTech.io
소스

1

우편 번호를 데이터베이스에 통합하려면 geonames 데이터베이스를 사용하는 것이 가장 좋습니다. 사용하고 이해하기 어렵지만 우리와 같은 사용자가 자유롭게 사용할 수있는 가장 큰 지리적 데이터베이스입니다.

다른 모든 데이터베이스는 거의 동일한 데이터 및 구조를 가질 가능성이 있습니다. 그들은 단지 데이터베이스에서 여분의 / 중복 정보를 제거합니다. 저 부하 시스템을 위해 무료 서비스를 사용하는 경우 제한이 매력적이며 json 및 ajax를 사용하여 더 쉬운 인터페이스를 제공합니다. 여기 에서 제한을 볼 수 있습니다.

참고로 varchar (20)은 우편 번호 저장에 충분합니다.

— 제이 카파시
소스