관계형 데이터베이스에 국제 지리적 주소를 어떻게 저장해야 합니까?

https://stackoverflow.com/questions/1159756

18-09-2019
|

문제

관계형 테이블에 국제 지리적 주소를 저장하는 작업을 고려할 때 가장 유연한 스키마는 무엇입니까?주소의 모든 부분을 해당 필드로 나누어야 합니까, 아니면 자유 텍스트와 비슷해야 합니까?

서로 다른 형식의 주소를 서로 다른 테이블로 분리하는 것이 의미가 있습니까?예를 들어 USAAddress, CanadianAddress, UKAddress...에 대한 테이블이 있습니까?

해결책

블로그 게시물에서 내 생각을 요약하겠습니다. 주소 스토리지의 레슨.

현재 프로젝트 [물류 회사에서 일하고] 국제 주소를 저장하고 있습니다. 데이터베이스 의이 부분을 설계 할 때 전 세계의 주소에 대한 연구를 수행했습니다. 다양한 형식이 있습니다. 서구 세계에서 우리는 상당히 균일 한 형식을 사용하는 경향이 있지만 몇 가지 차이점이지만 대부분은 다음과 같습니다.

거리 번호 - 숫자
집 또는 건물 이름 - [Varchar- 영국에서는 일부 주택/건물은 숫자가 아닌 이름으로 식별됩니다
거리 번호 접미사 Varchar, 대부분의 경우 char (1)가 충분하지만
- A, B 등
거리 이름 varchar
거리 유형 Streettypes 테이블이있는 경우 Varchar 또는 int
- 지금까지 나는 영어를 사용하는 세계에서 262 개의 독특한 유형을 발견했으며 더 많은 것이있을 가능성이 높으며 다른 언어, 즉 Strasse, Rue 등을 잊지 마십시오.
거리 방향 Varchar (2)
- N, E, S, W, NE, SE, NW, SW
주소 유형 varchar 또는 int 주소 유형 테이블이있는 경우
- 우편 사서함
- 아파트
- 건물
- 바닥
- 사무실
- 모음곡
- 등...
주소 유형 식별자 varchar
- 즉, 상자 번호, 아파트 번호, 바닥 번호 아파트 번호와 사무실에는 때때로 영숫자 정보가 있습니다.
지방 자치 단체 지방 자치 단체 테이블이있는 경우 varchar 또는 int
- 예를 들어, 햄릿/마을이 마을의 주소에 나타나는 경우.
도시/마을 도시 테이블이있는 경우 varchar 또는 int
통치 지구 지구 테이블이있는 경우 varchar 또는 int
- 주 (미국)
- 지방 (캐나다)
- 연방 지구 (멕시코)
- 카운티 (영국)
- 등...
우편 지역 varchar
- zip (미국)
- 우편 번호 (캐나다, 멕시코)
- 우편 번호 (영국)
국가 국가 테이블이있는 경우 varchar 또는 int

이것은 대부분의 국가를 다루는 것으로 보이지만 필드의 순서는 다르게 표시 될 수 있습니다. 디스플레이 형식 목록을 찾을 수 있습니다 http://www.bitboost.com/ref/international-address-formats.html#formats

예를 들어, 많은 국가에서 우편 번호는 도시 이름보다 먼저 떨어지고 거리 번호는 거리 이름으로 떨어집니다. 캐나다, 미국 및 영국에서는 거리 번호가 거리 이름보다 우선하며 우편 번호 (또는 Zip)는 도시 이름을 따라옵니다.

주소를 다른 나라로 분리하는 것에 대한 귀하의 질문에 대한 답변으로, 나는 그것을 제안하지 않을 것입니다. 예를 들어보고와 같은 다른 영역에서 삶을 더 어렵게 만들 것입니다. 내가 제공 한 형식은 아무런 문제없이 미국, 캐나다, 멕시코 및 영국을 다루는 물류 데이터베이스의 모든 주소를 다룹니다. 또한 모든 유럽, 중국, 일본 및 말레이시아 주소를 다룹니다. 나는 다른 나라에 대해서는 말할 수 없지만 아직이 분야가 지원하지 않는 국가의 주소를 보관할 필요는 없었습니다.

Alphanumeric 문자열에서 주소 정보를 구문 분석하는 것만 큼 간단하지 않기 때문에 주소 1, address2, address3 형식을 사용하는 것이 좋습니다. , 잘못된 정보, 오타, 틀린 등으로 인해 필드를 분리하는 경우 거리 알고리즘을 사용하여 의미를 확인할 수 있으며, 우편 번호 및 거리 번호에 대해 거리 이름을 점검하거나 거리 이름 등을 확인하는 확률을 사용하십시오. 전체 거리 주소를 나타내는 줄이있을 때 그 일을 수행합니다. 상상력이 늘어나는 것은 사소한 문제가 아닙니다.

주소 데이터베이스의 QA는 두통, 기간입니다. 이 영역에서의 삶을 단순화하는 가장 쉬운 방법은 모든 필드에 입학 시간에 올바른 것으로 자동으로 확인할 수있는 단일 정보 만 보유하는 것입니다. 확률, 거리 알고리즘 및 정규 표현식은 입력의 유효성을 확인하고 자신의 실수가 무엇인지에 대한 피드백을 제공하고 적절한 수정을 제안 할 수 있습니다.

알아야 할 경고는 거리 유형 인 이름이있는 도로입니다. 캐나다를 덮고 있다면 토론토의 "애비뉴로드"를 알고 있어야합니다. , 3 형식. 나는 다른 곳에서도 발생할 수 있지만, 나는 그들을 알지 못하지만 -이 단일 인스턴스는 WTF를 비명을 지르기에 충분 했습니까?!

다른 팁

주소 형식을 지나치게 분석하지 않도록주의하십시오. 그렇게하면 대부분의 사용자가 작업 해야하는 사양으로 끝날 가능성이 높습니다. 주위에, 효과적으로 잘못된 필드를 사용하도록 강요하거나 기본 필드를 채우고 추가 필드를 무시합니다.

물건을 단순하게 유지하십시오.

Benalabaster에서 언급 한 거리 유형은 영어 나 스페인어와 같은 언어를 분리하는 것과 다른 언어로 작업을 시작할 때 문제를 일으킬 것입니다.

암스테르담의 "Henriette" + "Roland Holst" + "Straat"에 세워진 암스테르담의 "Henriette Roland Holststraat"는 야생에서 얼마나 나쁜 일이 생길 수 있는지 보여줍니다. Roland Holststr. "또는"Hrholststr "로 철자가 틀렸다. 또는 날씨에 따라 "Henriette Roland-Holst Straat". 지구상의 각 국가에 대한 최신 거리 등록부가 없으면 아무데도 갈 수 없습니다.

마지막으로, 일부 다국어 국가에서는 이름이 다른 언어마다 다를 수 있습니다! 예를 들어 많은 거리가 프랑스어를 가진 브뤼셀에서 그리고 네덜란드어 이름 : "Avenu du Port"및 "Havenlaan"은 주소가 선호하는 언어에 따라. (Google Maps는 안전한면에있는 것만으로 두 가지 이름을 교대로 표시합니다.)

여기서 모든 종류의 영리한 트릭을 고안하려고 시도 할 수 있지만 영업 담당자입니다. 이것을 이해할 것입니까?

그것은 당신이 그것으로하고 싶은 것에 달려 있습니다.

분리 된 경우 다른 목적 (예 : USPS 데이터에 대한 확인 또는 UPS/FedEx로부터 배송 속도를 얻는 등)을 사용하는 것이 항상 더 쉽다는 것을 알았습니다.

주소에 일반적으로 사용하는 것은 다음과 같습니다.

주소 라인 1
주소 2
주소 라인 3
도시
지역
우편 번호
군
국가

편집에 대한 응답으로 : 대부분의 상황에서는 사용이 보이지 않습니다. 위에 나열된 표에는 대부분의 국가 주소에 대해 충분한 필드 (그리고 일반적으로 충분합니다).

주소

@BenAlabaster가 제공한 탁월한 답변과는 정반대로 다음과 같이 간단히 할 수 있습니다.

address       TEXT(300)
postal_code   VARCHAR(15)
country_code  VARCHAR(2)

클라이언트 측 양식 레이아웃은 여전히 원하는 만큼 복잡할 수 있습니다(또는 사용자가 주소를 수동으로 입력할 수 있는 여러 줄 입력을 사용).그런 다음 필요한 경우 주소에 줄 바꿈을 추가할 수 있습니다.

국가

국가 테이블은 다음과 같습니다.

country_code  VARCHAR(2)
country_name  VARCHAR(255)

추가적으로, 당신은 하나 다음 중:

postal_code_required  TINYINT(1)
postal_code_regex     VARCHAR(255) NULL DEFAULT NULL

그런 다음 다음 목록을 사용하여 국가 테이블을 디자인합니다.

이 질문을 우연히 발견한 사람을 위한 일화는 다음과 같습니다.

나는 많은 대륙(유럽, 아시아, 북미)에서 살면서 일해 본 사람으로서 말씀드립니다.내 경험과 함께 일하는 사람들의 경험에 따르면 다음을 수행하는 시스템을 사용하는 것이 훨씬 쉬웠습니다.

주소 하나를 입력할 세 줄을 입력하세요.이 세 줄을 제가 입력하는 대로 해당 지역 우편 서비스에 그대로 전달해 주세요.원하는 문자 세트를 사용하겠습니다.UTF-8 또는 더 나은 것을 사용하십시오.
시스템에 특정 정보(예: 우편번호, 현, 주 등)를 지정해야 하는 비즈니스 요구 사항이 있는 경우), 별도로 요청하세요.비즈니스 요구 사항이란 분석과 같은 것을 의미합니다.이러한 정보는 귀하의 지역 우편 서비스와 공유되어서는 안 됩니다(위의 1번 항목의 세 줄 중 하나에 동일한 정보를 쓰지 않는 한).
위의 1번 항목에 제공한 주소의 범주별 위치(예: 국가)를 지정하라는 드롭다운이 있습니다.
포인트 1에서 제가 제공한 정보를 구문 분석해야 한다면 포인트 3에 대한 답변을 사용하여 정규식을 선택하세요.포인트 1의 정보에 대해 해당 정규식을 실행하여 구문 분석합니다.정규식의 출력을 사용하여 포인트 2의 사용자 인터페이스 요소를 채우십시오.자동 완성된 정보를 수정하는 경우 제가 변경했다는 사실을 활용하여 정규식을 개선하세요.마찬가지로, 가능한 한 저에게 정규 표현식의 출력을 검토하고 수정할 수 있는 기회를 주십시오.내가 무엇을 전달하려고 했는지 나보다 더 잘 아는 사람은 없습니다.

이렇게 구축된 시스템은 내 삶을 더욱 편리하게 만들어줍니다.특히 귀하의 회사에 기능적 내부 지식이 거의 없는 우편 시스템으로 메일을 보낼 때 그렇습니다.

귀하의 회사가 특정 우편 시스템에 대한 내부 지식을 갖고 있는 경우 포인트 3에서 제가 선택한 내용을 사용하여 귀하가 나에게 표시할 보기를 알려주십시오.많은 사람들이 미국 우편 시스템이 포장에 대해 무엇을 기대하는지 알고 있습니다.포인트 3에서 US를 선택했다면 미국 주소에 맞게 뷰를 표시해도 됩니다.귀하의 회사가 전혀 모르는 국가를 선택하는 경우 일반적인 세 줄을 표시하고 나머지는 제가 하도록 합니다.나에게 ASCII를 사용하도록 강요하지 마세요.

현실적으로 모든 글로벌 우편 시스템(공공 및 민간)에 대한 완전한 백과사전적 데이터베이스를 구축하는 것은 불가능하지는 않더라도 기껏해야 엄청난 작업입니다.예를 들어, 지역 라스트마일 운송업체만이 주소가 어디에 있는지 실제로 알 수 있는 우편 시스템이 있습니다.때로는 포장에 있는 해당 운송업체에 메모를 전달할 수 있는 것이 매우 유용합니다.그리고 모든 특수 케이스 운송업체의 현지 지식을 데이터베이스에 매핑하는 것은 실제로 불가능한 작업입니다.

괴델에게 물어보세요.(그런 다음 담론의 세계를 모델링하기 위해 공리 시스템을 사용하려고 하는지, 집합론이나 관계 대수와 같은 일종의 산술을 주고받는지 스스로에게 물어보세요.)

Ben Alabaster의 답변에 대한 의견 : 국가를 기반으로 주소를 형식화하려면 각 국가의 열을 별도의 행으로 주문하는 서식 테이블을 사용할 수 있습니다.

jesserformat (CountryCode, FieldName, Fieldorder)

현장 순서는 복잡한 그리드 레이아웃을 사용하도록 코딩 할 수 있습니다.

국가별로 주소를 분리 할 필요는 없습니다. 국가의 수가 증가함에 따라 혼란 스러울 것이며 국제 고객의 모든 주소를 찾고 싶다면 곤경에 처할 것입니다. 벤이 제안한 주소 유형을 갖는 것은 건물 번호와 아파트 번호가 모두있는 주소가있을 때 모호성을 초래할 수 있습니다. 나는 각 건물의 이름이 다른 아파트 단지에있을 수 있습니다. 이것은 인도에서 매우 흔합니다.

나는 사용한다 https://github.com/commerceguys/addressing 국제 주소를 포맷하고 이러한 요소를 사용하는 도서관 :

Country
Administrative area
Locality (City)
Dependent Locality (in: BR, CN, IR, MY, MX, NZ, PH, KR, ZA, TH)
Postal code
Sorting code
Address line 1
Address line 2
Organization
Recipient

거리를 구문 분석하고 싶다면 도움이되지 않습니다 (이름, 집 번호 ...).

BTW. 다중 언어 국가 목록을 찾고 있다면 : https://github.com/umpirsky/country-list

유일한 방법은 다음과 같이 분할하는 것입니다.

Name varchar,
Title varchar,
StreetAddress varchar,
StreetAddressLine2 varchar,
zipCode varchar,
City varchar,
Province varchar,
Country lookup

거의 모든 국가에는 주소 데이터가있는 자체 표준이므로 Evey 국가는 다른 형식의 우편 번호를 가지고 있습니다.
작은 문제가 생길 수 있습니다 내 게시물 비슷한 질문에서.

주소 규칙이 거의없는 국가가 있기 때문에 모든 국가의 주소를 분리하는 것은 의미가 없습니다. 일부 인기있는 대법원에는 작은 마을에는 거리가없고 마을 이름과 숫자 만 포함되며 거리는 더 큰 도시의 주소에 있습니다. 나는 헝가리의 수도 인 부다페스트에서 같은 이름을 가진 거리가 거의 없다는 것을 배웠습니다 (도시의 지구 번호로 구별) 다른 도시에는 그러한 주소가 없습니다 (헝가리 출신의 누군가가 이것이 사실인지 확인할 수 있습니다). 따라서 총 주소 형식의 수는 Numer_of_Countries 에이 나라의 주소 형식 수를 곱한 것입니다. 다른 테이블로 수행 할 수 있지만 끔찍한 작업이 될 것입니다.

나는 이것이 이미 대답 된 매우 오래된 주제라는 것을 알고 있지만, 나는 두 센트를 던질 것이라고 생각했다. 그것은 모두 프로젝트 목표와 대상 사용자가 주소를 입력 할 것으로 기대하는 방법에 따라 다릅니다. Ben의 제안은 당신이 정확하게 주소를 구문 분석 할 수있게하지만 반면에 더 길고 (그리고 더 실망스러운) 사용자 데이터 입력 프로세스를 만들 수 있습니다. Stephen Wrighton의 제안은 더 간단하며 결과적으로 사용자가 주소를 입력하기가 더 쉬울 수 있습니다.

또한 도시, 국가, 지역 등을 유지하는 동안 한 열에 전형적인 거리 번호, 유형, 거리 이름, 단위 / 아파트 번호 등을 캡처하는 "주소"열이있는 일부 모델을 보았습니다. 다른 열 내에서. Stephen의 모델과 유사하며 주소 1, address2 및 address3을 제외하고는 모두 하나의 열로 통합되었습니다.

내 의견은 가장 유연한 모델이 유연성에 대한 해석에 따라 가장 제한적인 모델 인 경향이 있다는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow