세계의 모든 주소에 대한 공통 주소 데이터베이스 디자인이 있습니까?

저는 프로그래머이고 솔직히 말해서 세계의 주소 구조를 모릅니다. 우리나라에서 어떻게 구조화되어 있는지 :) 그렇다면 주소를 저장하는 데 가장 좋고 일반적인 데이터베이스 디자인은 무엇입니까? 하나의 ID
로만 식별되는 세계의 모든 주소를 저장하는 것은 사용하기 쉽고 쿼리가 빠르며 동적이어야합니다. 감사합니다.

표준 필드 집합에서 여러 국가의 주소를 나타낼 수 있습니다. 명명되거나 번호가 매겨진 건물이 위치한 명명 된 접근 경로 (도로)의 기본 아이디어는 중국에서 가끔씩을 제외하고는 상당히 표준 적입니다. 다른 거의 보편적 인 개념은 다음과 같습니다. 일반적으로 지역이라고 할 수있는 정착지 (도시 / 타운 / 마을) 이름 지정; 지역 이름을 지정하고 영숫자 우편 번호를 할당합니다. 우편 번호라고도하는 우편 번호는 일부 국가에서만 순전히 숫자입니다. 정말로 제네릭을 원한다면 많은 필드가 필요합니다.

UPU Universal Postal Union은 표준 형식으로 많은 국가의 주소 데이터를 제공 합니다 . UPU 형식은 전체 국가의 모든 주소 (사용 가능한 필드 정밀도까지)를 보유하므로 관계형입니다. 가능한 모든 주소의 일부만 저장되는 고객 주소를 저장하는 경우 모든 필드와 행당 하나의 주소를 포함하는 단일 테이블 (또는 플랫 형식)을 사용하는 것이 좋습니다.

주소를 저장하는 데 적합한 형식은 다음과 같습니다.

• 주소 라인 1-4
• 소재지
• 부위
• 우편 번호 (또는 우편 번호)
• 국가

주소 라인 1-4는 다음과 같은 구성 요소를 포함 할 수 있습니다.

• 건물
• 하위 건물
• 구내 번호 (번지)
• 전제 범위
• 도로
• 하위 도로
• 이중 종속 지역
• 하위 지역

자주 3 개의 주소 라인 만 사용되지만 이는 종종 충분하지 않습니다. 물론 공식 형식으로 모든 주소를 나타 내기 위해 더 많은 줄이 필요할 수 있지만 쉼표는 항상 줄 구분 기호로 사용할 수 있으므로 정보를 계속 캡처 할 수 있습니다.

일반적으로 데이터 분석은 지역, 지역, 우편 번호 및 국가별로 수행되며 이러한 요소는 사용자가 데이터를 입력 할 때 이해하기 매우 쉽습니다. 이것이 이러한 요소를 별도의 필드로 저장해야하는 이유입니다. 그러나 사용자에게 우편 번호 또는 지역을 입력하도록 강요하지 마십시오. 로컬에서 사용할 수 없습니다.

지역 성은 명확하지 않을 수 있으며, 특히지도 지역과 우편 지역의 구분이 명확하지 않을 수 있습니다. 우편 지역은 우체국이 인정하는 지역으로, 때로는 인근의 큰 도시 일 수 있습니다. 그러나 우편 번호는 일반적으로 문제 나 불일치를 해결하여 공식 우편 지역을 사용하지 않더라도 올바른 배송을 허용합니다.

Database Answers를 살펴보십시오 . 특히 다음과 같은 많은 경우를 다룹니다.

(모든 가변 길이 문자 데이터 유형)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

이 데이터를 저장 하는 주요 목적 이 무엇인지 자문 해보십시오 . 실제로 해당 주소의 사람에게 메일을 보내시겠습니까? 인구 통계, 인구를 추적 하시겠습니까? 기본적인 인증 / 확인의 일부로 발신자에게 정확한 주소를 요청할 수 있습니까? 무엇보다도? 위의 어느 것도 없습니까?

실제 필요에 따라 a) 실제로 중요하지 않으며 자유 텍스트 접근 방식을 선택하거나 b) 모든 국가에 대한 구조화 / 특정 필드 또는 c) 국가 별 아키텍처를 결정할 수 있습니다.

때로는 거리 주소에 가장 가까운 곳이 도시입니다.

인도의 모든 중등 학교를 Google지도에 넣는 프로젝트가있었습니다. Google API를 사용하여 멋진 프로그램을 작성했으며 매우 쉬울 것이라고 생각했습니다.

그런 다음 클라이언트로부터 데이터를 얻었습니다. 일부 학교 주소는 "시장 건너편, 이발소 옆"또는 "오래된 버스 정류장 근처"와 같은 것입니다.

불행히도 Google API가 해당 형식을 지원하지 않기 때문에 내 작업이 훨씬 더 어려워졌습니다.

국제 주소의 경우 정보를 필드로 분류하면 형식을 지정하는 방법을 찾기가 매우 어렵습니다. 예를 들어 이탈리아 주소는 다음을 사용합니다.

<street address>
<zip> <town> <region>
<country>

같은

Via Eroi della Repubblica
89861 Tropea VV
Italy

두 번째 줄의 미국 주소 순서와는 다소 다릅니다.

SO 질문도 참조하십시오.

• 영국 데이터베이스에 사용할 주소 필드는 몇 개입니까?
• 주소를 거리 /시 /도 / 우편 번호로 나눕니 까?
• 중복 된 거리 접미사를 어떻게 처리합니까?
• 데이터베이스 (RDBMS)에 우편 주소를 저장하는 모범 사례?

' 우편 번호 ' 태그도 확인하세요 .

편집 : 지역과 마을의 역순 -UPU 당

아마도 이것은 유용 할 것입니다 : https://gist.github.com/259744 프로젝트를 위해 ISO 코드, 최상위 도메인, 전화 코드, 자동차 사인, 길이 및 정규식을 포함하여 세계 모든 국가에 대한 정보 테이블을 수집했습니다. 지퍼. 불행히도 국가 이름과 주석은 독일어로만 제공됩니다.

필드와 함께 갈 준비가 된 자유 형식에 따라 다릅니다. 하나의 자유 형식 주소 필드는 분명히 항상 가능하지만 지리적 범위를 좁히는 데 상대적으로 거의 도움이되지 않습니다.

문제는 국가별로 지리적 계층 수준에 너무 많은 차이가 있다는 것입니다. 도대체 '거리 주소'가없는 국가도 있습니다.

너무 영리하게 만들려고하지 않는 것이 좋습니다.

여기에 다른 답변과 달리 구조화 된 주소 데이터베이스를 가질 수 있다고 생각합니다.

모자에서 다음과 같은 구조를 생각할 수 있습니다.

• 국가
• 지역 (주 /도)
• 지역 (시 /시)
• 하위 지역 (지역의 카운티 / 기타 하위 구역)
• 거리

그러나 충분히 빠르게 쿼리하는 방법은 무엇입니까?

내가 항상 성취 할 수 있다고 생각하는 한 가지 방법은 국가마다 다르지만 국가 내에서 확고한 우편 번호 (또는 우편 번호)를 요청하는 것입니다.

이렇게하면 전 세계 우체국에서 제공하는 정보를 중심으로 데이터를 구조화 할 수 있습니다.

Universal Data Model 명성 의 Len Silverston은 GEOGRAPHIC BOUNDARIES단순한 STREET ADDRESS LINEs 또는 국가 별 파생물을 기꺼이 받아들이 려는 자유 형식의 정도에 따라 별도의 계층 구조를 권장합니다 .

아뇨, 절대 아닙니다. 미국과 일본 주소가 작동 하는 방식을 비교하면 불가능하다는 것을 알 수 있습니다.

최신 정보:

다시 생각하면 무엇이든 할 수 있지만 상충 관계가 있습니다.

한 가지 접근 방식은 address 및 address_attribute 테이블의 문제를 1 : m 관계로 모델링하는 것입니다. 무엇이든 모델링 할 수 있습니다. address_attribute 테이블에는 pk, 이름, 값 및 주소 부모의 pk를 다시 가리키는 fk가 있습니다. 이름, 값 쌍이있는 맵을 사용하는 것과 거의 같습니다.

트레이드 오프는 주소를 원할 때마다 JOIN을 수행해야한다는 것입니다. 또한 매번 처리하는 내용을 파악하기 위해 address_attributes의 이름을 조사해야합니다.

또 다른 접근 방식은 전 세계에서 주소를 모델링하는 방법에 대한보다 포괄적 인 연구를 수행하는 것입니다. 객체 지향 세계에서는 주소 공간을 타일링하는 데 필요한만큼 서양 주소 클래스 (street1 / street2 / city / state / zip)와 일본, 중국에 대한 기타 클래스가있을 수 있습니다. 그런 다음 마스터 주소 테이블과 하위 테이블이 1 : 1 관계로 다른 유형에 대해 제공됩니다.

Amazon 또는 eBay는 어떻게합니까? 그들은 국제적으로 배송됩니다. 로케일 별 UI 기능이 있습니까? 미국 로케일 만 사용했습니다.

아니요, 표준 주소 지정 체계가 없습니다. 일반적으로 국가마다 다릅니다. 만국 우편 연합 (Universal Postal Union) 조차도 모든 사람 을 위한 주소 인 Adressing the world에 대해 말했다 . 이를위한 최선의 해결책은 ISO 3166으로 알려진 2/3 자 국가 코드 표준을 사용하고 그 밖의 모든 것을 국가 표준에 따라 처리하는 것입니다.

그러나 프로젝트에서 쉽게 액세스 할 수있는 도구를 사용하고 싶다면 Google Place API를 사용해 볼 수 있습니다 .

디자인은 목적에 따라 크게 달라야합니다. 어떤 사람들은 데이터 구조화 방법을 게시했습니다. 따라서 단순히 누군가에게 s- 메일을 보내고 싶다면 그렇게 할 것입니다. 이 데이터를 탐색에 사용하려면 상황이 복잡해지기 시작합니다. 자동차 내비게이션에는 교통 정보 (예 : 일방 통행 도로)를 포함하기위한 추가 구조가 필요하지만 도보 내비게이션에는 많은 추가 데이터가 필요합니다. 여기에 작은 예가 있습니다. 우리 도시에서는 이웃이 공원 근처에 있습니다. 공원 옆에는 이전 비행장 (사실 유럽에서 가장 오래된 비행장 중 하나)이 항공 박물관으로 바뀌 었습니다. 항공 박물관 옆에는 비즈니스 파크가 있습니다. 박물관의 거리 번호는 39이고 비즈니스 파크 번호는 39A로 시작합니다. 따라서 39A와 39A가 가까워 보일 수 있지만 서로 걸어서 이동하는 데 약 1 마일이 걸립니다 (자동차로 갈 경우 더 오래 걸립니다).
이것은 우리 도시에서 가져온 작은 예일뿐입니다. 아마도 많은 예외를 찾을 수있을 것입니다 (특히 모든 국가의 시골이나 야생 지역에서).