데이터베이스 (RDBMS)에 우편 주소를 저장하는 모범 사례?

RDBMS에 우편 주소를 저장하는 모범 사례에 대한 좋은 참조가 있습니까? 만들 수있는 많은 장단점이 있고 각각에 대해 많은 장단점을 평가해야하는 것 같습니다. 확실히 이것은 몇 번이고 반복 되었습니까? 누군가 적어도 어딘가에서 배운 교훈을 쓴 적이 있습니까?

내가 말하는 절충점의 예는 우편 번호를 정수 대 문자 필드로 저장하는 것입니다. 집 번호를 별도의 필드 또는 주소 행 1의 일부로 저장해야하는지, 스위트 / 아파트 / 기타 번호가 정규화되거나 주소 줄 2의 텍스트 덩어리, zip +4 (별도 필드 또는 하나의 큰 필드, 정수 대 텍스트)를 어떻게 처리합니까? 기타

저는이 시점에서 주로 미국 주소에 관심이 있지만 글로벌화의 결과에 대비하기위한 몇 가지 모범 사례가 있다고 생각합니다 (예 : 우편 번호 대신 주 또는 우편 번호 대신 지역과 같은 필드 이름 지정, 기타

더 많은 국제적 사용을 위해 고려할 하나의 스키마는 Drupal 주소 필드에서 사용하는 스키마 입니다. xNAL 표준을 기반으로하며 대부분의 국제 사례를 다루는 것으로 보입니다. 이 모듈을 조금만 파헤쳐 보면 국제적으로 주소를 해석하고 검증 할 수있는 좋은 진주가 나올 것입니다. 또한 ISO 코드가있는 멋진 행정 구역 (도, 주, 주 등)이 있습니다.

다음은 모듈 페이지에서 복사 한 스키마의 요점입니다.

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

내가 배운 교훈 :

• 숫자로 아무것도 저장하지 마십시오.
• 가능한 경우 국가 및 행정 구역을 ISO 코드로 저장하십시오.
• 모를 때는 필드 요구에 대해 느슨해 지십시오. 일부 국가에서는 locality& 와 같은 기본적인 것조차도 당연하게 여기는 필드를 사용하지 않을 수 있습니다 thoroughfare.

'국제'사용자로서 미국 형식 주소만을 지향하는 웹 사이트를 다루는 것보다 더 실망스러운 것은 없습니다. 처음에는 약간 무례하지만 유효성 검사도 지나치게 열성적 일 때는 심각한 문제가됩니다.

글로벌화에 관심이 있으시다면 제가 할 수있는 유일한 조언은 자유 형식을 유지하는 것입니다. 국가마다 규칙이 다릅니다. 일부에서는 집 번호가 거리 이름 앞에 나오고 일부에서는 그 뒤에옵니다. 일부에는 주, 일부 지역, 일부 카운티, 일부 조합이 있습니다. 여기 영국에서는 우편 번호가 우편 번호가 아니라 문자와 숫자가 모두 포함 된 우편 번호입니다.

우편 번호에 대한 별도의 필드와 함께 ~ 10 줄의 가변 길이 문자열을 권장합니다. 사용자 / 고객이 주소 작성 방법을 결정하게하십시오.

다른 국가에서 우편 주소를 사용하는 방법에 대한 포괄적 인 정보가 필요한 경우 다음은 매우 좋은 참조 링크입니다 (Columbia University).

우편 주소에 대한 Frank의 강박 지침 효과적인 국제 우편 주소
지정

"half-numbers"또는 "129A"와 같은 내 현재 주소와 같은 특수한 경우 때문에 집 번호를 숫자가 아닌 문자 필드로 저장하는 것을 확실히 고려해야합니다. 그러나 A는 아파트로 간주되지 않습니다. 배달 서비스 번호.

저는이 작업을 수행했으며 (데이터베이스에서 주소 구조를 엄격하게 모델링), 다시는하지 않을 것입니다. 일반적으로 고려해야 할 예외가 얼마나 미친 지 상상할 수 없습니다.

나는 노르웨이 우편 번호 (내 생각에)와 관련된 문제를 모호하게 기억한다. (내 생각에는) 18 개 정도의 오슬로를 제외하고 모두 4 개 위치였다.

나는 우리가 모든 국가 주소에 대해 지리적으로 정확한 우편 번호를 사용하기 시작한 순간부터 꽤 많은 사람들이 그들의 우편물이 너무 늦게 도착했다고 불평하기 시작했다고 확신합니다. 그 사람들은 우편 지역 사이의 경계선 근처에 살고 있었고 누군가가 실제로 우편 지역 (예 : 1600)에 살았음에도 불구하고 실제로 그의 우편물은 우편 지역 1610으로 발송되어야합니다. 왜냐하면 실제로는 이웃 우편 지역 이었기 때문입니다. 우편물을 올바른 우편 지역으로 보내면 우편물을 잘못된 우편 지역으로 전달하기 위해 올바른 우체국에서 원치 않는 개입이 필요했기 때문에 우편물이 도착하는 데 며칠 더 걸릴 것입니다.

(우리는 ISO 코드 'ZZ'로 국가에 해외 주소를 가진 사람들을 등록했습니다.)

" 이것이 관계형 데이터베이스에서 주소 정보를 모델링하는 좋은 방법입니까? "를 반드시 참조해야 하지만 귀하의 질문은 그것과 직접적으로 중복되지 않습니다.

분명히 많은 기존 답변이 있습니다 (예 를 들어 DatabaseAnswers 에서 예제 데이터 모델 확인 ). 기존 답변의 대부분은 일부 상황에서 결함이 있습니다 (DB Answers를 전혀 선택하지 않음).

고려해야 할 한 가지 주요 문제는 주소 범위입니다. 데이터베이스가 국제 주소를 처리해야하는 경우 한 국가의 주소 만 처리해야하는 경우보다 더 유연해야합니다.

제 생각에는 주소의 '주소 라벨 이미지'를 기록하고 콘텐츠를 개별적으로 분석하는 것이 종종 ( 항상 그런 것은 아닙니다 ) 현명합니다. 이를 통해 우편 번호 배치 간의 차이 (예 : 다른 국가 간의 차이)를 처리 할 수 ​​있습니다. 물론, 다른 국가의 편심을 처리하는 분석기와 포맷터를 작성할 수 있습니다 (예를 들어 미국 주소에는 2 줄 또는 3 줄이 있고, 반대로 영국 주소에는 상당히 더 많을 수 있습니다. 주기적으로 쓰는 주소에는 9 줄이 있습니다). 그러나 사람이 분석 및 서식을 지정하고 DBMS가 데이터를 저장하도록하는 것이 더 쉬울 수 있습니다.

거리 번호 나 우편 번호에 대한 수학을하지 않는 한, 숫자로 저장하여 미래의 고통을 불러 일으키는 것입니다.

여기저기서 몇 바이트를 절약하고 더 빠른 색인을 얻을 수 있지만 미국 우편 또는 귀하가 거래하는 다른 국가에서 코드에 알파를 도입 할 때 어떻게해야합니까?

디스크 공간의 비용은 나중에 고치는 비용보다 훨씬 저렴할 것입니다 ... y2k 누구?

무엇에 추가 @ Jonathan Leffler 와 @ Paul Fisher 가 말한 내용에 추가

캐나다 또는 멕시코의 우편 주소가 요구 사항에 추가 될 것으로 예상되는 경우 postal-code문자열로 저장 하는 것이 필수입니다. 캐나다에는 영숫자 우편 번호가 있는데 멕시코가 내 머리 위로 어떻게 생겼는지 기억이 나지 않습니다.

Ive는 가장 작은 개별 단위에서 가장 큰 단위까지 가능한 모든 필드를 나열하는 것이 가장 쉬운 방법임을 발견했습니다. 사용자는 자신에게 적합하다고 생각되는 필드를 채울 것입니다. 내 주소 테이블은 다음과 같습니다.

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

ZIP을 NUMBER 또는 VARCHAR로 저장하는 "거래"는 어디에 있습니까? 그것은 단지 선택 일뿐입니다. 두 가지 모두에게 혜택이 있고 다른 사람을 얻기 위해 몇 가지 혜택을 포기해야하는 경우가 아니라면 트레이드 오프가 아닙니다.

zip의 합계가 전혀 의미가없는 한, Zips as number는 유용하지 않습니다.

이는 과잉 일 수 있지만 여러 국가에서 작동하는 솔루션이 필요하고 주소의 일부를 프로그래밍 방식으로 처리해야하는 경우 :

두 개의 테이블을 사용하여 국가 별 주소를 처리 할 수 ​​있습니다. 하나는 VARCHAR2 열 10 개, 숫자 열 10 개, 이러한 필드를 프롬프트에 매핑하고 주소 구조를 국가에 연결하는 국가 열이있는 다른 테이블입니다.

주소를 확인하거나 신용 카드 결제를 처리하는 데 사용해야하는 경우 최소한 약간의 구조가 필요합니다. 자유 형식의 텍스트 블록은 이에 대해 잘 작동하지 않습니다.

우편 번호는 전체 주소를 사용하지 않고 결제 카드 거래를 확인하기위한 일반적인 선택 필드입니다. 따라서 별도의 넉넉한 크기의 필드를 만드십시오 (최소 10 자).

Database Answers에서 영감을 얻음

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

모든 필드를 큰 NVARCHAR (1000) 필드에 모으고 사용자가 값을 입력 할 수있는 텍스트 영역 요소를 사용합니다 (예 : 우편 번호에 대한 분석을 수행하려는 경우 제외). 주소 라인 1, 주소 라인 2 등의 모든 입력은 해당 형식에 맞지 않는 주소가있는 경우 매우 성가신 일입니다 (미국 이외의 국가가 있음).