지리적 주소 / 위치를 데이터베이스에 저장하는 보편적 인 방법은 무엇입니까? [닫은]

지구상의 모든 주소에 적합한 지리적 주소 / 위치의 올바른 형식은 무엇입니까? 현재 나는 :

• 국가
• 시티
• 거리
• 번호
• 텍스트 데이터 (간단 성을 위해)
• 지퍼
• 위도 / 경도

그러나 나는 그것을 개선 할 수 있다고 생각합니다 : 국가의 주 / 지역 또는 지역과 같은 것이있을 수 있습니다. 또는 싱가포르 나 홍콩에 지역 / 지역 / 주가 없습니다.

거리는 없지만 도로 나대로 또는 다른 것이있을 수 있습니다. 여러 건물이 복합적 일 수 있습니다. 바닥이있을 수 있습니다. 방 번호. 기타....

Google은 전 세계 모든 국가의 우편 주소를 확인하는 데 도움이 되는 라이브러리 를 개발했습니다.이 라이브러리 를 사용하여이 데이터를 저장하기위한 스키마를 디자인 할 수 있습니다.

대상 고객층의 주소에서 가장 일반적인 필수 필드를 찾아 시작하고, 다른 요구 사항을 가진 다른 국가를 식별 할 때 스키마를 계속 조정할 수 있습니다.

지리적 주소 / 위치를 데이터베이스에 저장하는 일반적인 방법은 다음과 같습니다.

[Address] nvarchar(max) not null

이를 위해서는 최소한의 프로그래밍 코드가 필요하므로 유지 관리 비용이 절감되며 모든 주소와 완벽하게 호환됩니다. 그러나 세 가지 큰 문제가 있습니다.

• 데이터 유효성 검사가 없다는 것은 주소를 저장하는 것 이외의 목적으로 필드를 사용할 수 있음을 의미합니다. 목적 중 하나는 주소 필드에 2GB의 데이터를 입력하여 데이터베이스 공간을 채우려는 DOS 공격입니다.

• 이러한 방식으로 저장된 데이터는 비즈니스 인텔리전스 및 데이터 마이닝 목적으로 데이터를 처리 할 수 ​​없습니다. 예를 들어 인도 출신 사용자는 몇 명입니까? 이러한 주소는 정규화되지 않으므로 알 수있는 쉬운 방법이 없습니다.

• 사용자가 실수로 불완전하거나 명백하게 잘못된 주소를 입력 할 수 있습니다.

첫 번째 문제를 완화하려면 필드를 합리적인 한계라고 생각하는 범위로 제한하십시오. 개인적으로, 나는 1000 문자로 시작한 다음 데이터 세트를 충분히 얻었을 때 첫 번째 사용자가 입력 한 주소의 길이에 따라 줄입니다.

다른 두 가지 문제를 완화하기 위해 주소를 구문 분석하고 국가, 도시, 우편 번호 등이 포함 된 데이터를 제공하는 타사 API를 사용할 수 있습니다. 가능하면 API에서 주소를 표시 할 수 있어야합니다. 사용자가 불완전하거나 잘못된 주소를 입력 할 위험을 줄이기 위해 사용자에게 되돌아가는지도 : 대부분의 사용자는 거주 지역을 알고 있으며지도에서 다른 위치를 보면 즉시 입력 내용을 확인해야 할 단서가됩니다.

어떤 API를 사용하든 완벽하지는 않습니다. 대부분의 주소를 찾을 수 있지만 모든 주소를 찾을 수는 없습니다. 이는 API가 주소가 존재하지 않는다고 말하지만 사용자가이를 주장하는 경우 , 사용자가 틀렸더라도 우선 순위를 신뢰 해야한다는 것을 의미합니다 .

이는 또한 원래 사용자의 입력을 API 결과와 나란히 저장해야 함을 의미합니다. 이는 스키마가 다음과 같이됨을 의미합니다.

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

없어요

국가마다 주소 형식이 다릅니다. 운이 좋으면 형식이 전혀 없습니다!

분명히 위도 / 경도는 지구상에 대한 요점을 제공하지만 개별 주택을 식별하는 데 실제로는 유용하지 않습니다. 예를 들어 타워 블록을 고려하십시오.

가장 좋은 방법은 각 국가의 우편 서비스에서 공식 형식을 확인하는 것입니다. 백엔드 데이터베이스에 유용 할 수 있습니다. 그러나 대부분의 사람들이 사용하는 것보다 더 많은 필드를 포함하므로 최종 사용자를 위해 단순화해야 할 것입니다.

예를 들어 영국에는 '이중 의존성 지역'과 같은 것들이 포함되어 있지만 요청한 경우 그 의미를 아는 사람은 아무도 없습니다.

유일한 범용 형식은 여러 줄의 텍스트를 가질 수있는 단일 텍스트 필드를 갖는 것입니다. 이것은 지상에서 가능한 모든 주소를 허용합니다.

많은 국가에서 사용할 소프트웨어 솔루션을 개발하고 있습니다. 우리는 먼저 더 큰 실체를 시작하여이 문제를 해결합니다. 즉, 국가는 가장 흔하지 않거나 가장 작은 필드를 갖습니다. 지금까지 실험 한 모든 국가에서 잘 작동합니다. 우리는 또한 똑똑한 복제 방지 시스템을 가지고 있으며 사용자가 매우 '창의적'이므로 시스템에 들어간 사람들을 위해 합병합니다. 관리자 섹션에는 국가 별 주소 필드 순서 설정이 있습니다. 즉, 일본은 영국 / 미국이 마지막 인 우편 번호를 먼저가집니다.

일반적으로 다음을 사용합니다.

• 국가
• 우편 번호
• 주 /도 / 현 / 현
• 도시 / 마을 / 마을
• 거리 / 도로 / 블록
• 건물 이름 / 번호
• 특정 / 사용자 정의 정보

필드를 입력하고 저장하면 필요하지 않은 필드를 제외하고 공액 버전을 표시 할 수 있습니다.

내가 말했듯이, 이것은 소프트웨어가있는 모든 국가에서 작동하며 1989 년 이래 개발의 결과입니다.

이것이 어떻게 든 도움이되거나 적어도 다른 통찰력을 제공하기를 바랍니다.

이미 언급했듯이 가장 보편적이지만 (유효성이없고 가장 유용하지 않은) 단일 단일 유니 코드 필드입니다.

국가를 나머지 주소와 분리하여 ISO 국가 코드로 저장할 수 있습니다. 국가를 정상화하고 주소의 나머지 부분을 검증하는 데 약간의 유용성을 제공합니다.

우편 번호 일명 우편 번호를 나머지 주소와 분리 할 수도 있습니다. 이것은 또한 주소의 나머지 부분을 검증하는 데 유용하며 지리적 위치에 도움이 될 수 있습니다. 예를 들어, 캐나다에서는 우편 번호와 거리 번호 (일명 주택 번호) 만 지정하여 주소를 고유하게 식별 할 수 있습니다. 이것은 모든 국가에서 사실이 아닙니다.

각 주가 주소를 구성하는 방식의 변화로 인해 주 /도 또는 도시에 전념하는 것이 더 문제가되기 시작합니다. 초기 청중이 북미에 초점을 맞추고 국제 청중이 문제를 일으킬 수 있음을 알고 있기 때문에 이러한 필드를 갖는 주소 테이블을 설정했습니다. 어색하고 잠재적으로 오류가 발생하기 쉬운 타협-확실히 보편적 인 것은 아닙니다.

Mitchdav의 답변과 달리 Google 라이브러리를 사용하지 않는 것이 좋습니다. 단위 테스트 데이터를 찾기 위해 정통 주소 지정 체계를 사용하여 다양한 국제 장소에 대한 저장소를 검색했지만 걱정스럽게도 전체 저장소에서 히트가 전혀 없었습니다.

가장 좋은 방법은 주소를 자유 형식의 여러 줄 텍스트로 취급하는 것입니다. 모든 주소를 확인할 수는 없지만 일부 주소 형식은 실제로 이상하고 예상 할 수 없으며 결국 올바른 주소를 작성하는 책임은 사용자에게 있으며 대부분의 응용 프로그램에서 사용자는 잘못된 주소.

유효성 검사기를 사용하여 경고 를 제공 할 수 있지만 그 이상은 아닙니다. 그러나 확인되지 않은 주소는 거부하지 마십시오. 그렇지 않으면 일부 고객이 손실 될 수 있습니다. 사용자가 이상한 주소 형식의 지역에 거주하는 경우 경고를 무시하는 것이 안전하다는 것을 알리는 방식으로 사용자에게 경고하는 방법에 대한 질문으로 이어집니다.

당신이 지구상의 어떤 주소 를 말했듯 이 단지 위도는 길거나 ...

https://what3words.com

3 단어는 지구상의 어느 곳에서나 3x3 미터 패치를 정의 할 수있는 알고리즘 (데이터베이스가 아니므로 어떤 것에도 포함될 수 있음)입니다.

통가와 몇몇 다른 주에서는이 코드를 우편 시스템으로 채택했지만, 시원하고 아주 잘 짜여진 오버레이로 대체 할 수는 없습니다.