거리 주소 데이터를 문자열로 저장하는 대신 별도로 저장하면 이점이 있나요?

https://stackoverflow.com/questions/1626432

06-07-2019
|

문제

현재 우리는 주소 데이터를 다음과 같이 저장합니다:

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

하지만 주소를 처리하고 가져올 때 처음 5개의 주소 부분을 구문 분석하는 (내가 알 수 있는 공통적인) 문제에 직면하고 있습니다.

나는 거리 주소가 단지 문자열(db의 varchar)이라면 이 모든 것이 훨씬 더 쉬울 것이라고 생각합니다.

현재 상태를 유지해야 하는 이유에 대해 제가 제시한 두 가지 주장이 있습니다.1.거리 이름이나 번호 등으로만 검색할 수 있으면 검색이 더 쉽습니다.하지만 SELECT x FROM Address WHERE streetAddress LIKE "% 줄을 따라 SQL 스크립트가 있다고 생각합니다.입력%";물론 빠르지는 않지만 작동할 것입니다(그리고 해당 검색에 대한 데이터 세트는 고객에게만 해당되며 우리가 저장한 모든 주소 세트보다 엄청나게 작습니다).

현재 우리는 아파트에 플래그를 지정하는 시스템을 갖추고 있습니다. 주소 A에 있는 사람 1명이 아파트라는 것을 알게 되면 우리는 그 사람에게 플래그를 지정하고 해당 거리/거리 이름에 있는 다른 모든 사람을 검색하여 그들에게도 플래그를 지정합니다(이것은 때때로 중요한 비즈니스 요구 사항)

주소에는 수많은 예외가 있기 때문에 이미 모두 문자열로 저장했습니다.

그렇다면 주소 부분을 별도로 저장해야 하거나 원하는 특별한 이유가 있는지 묻고 싶습니다.

해결책

나는 이것에 관해 전체 블로그 게시물을 얼마 전에 썼습니다.각 데이터 조각을 별도의 필드에 저장해야 하는 데는 그만한 이유가 있습니다.특히 주소 데이터의 유효성을 검사하는 경우입니다.

물론, 귀하가 속한 업계와 정보가 어떤 용도로 사용되는지에 따라 다릅니다.잘못된 주소 데이터로 인해 회사에 비용이 발생하지 않는다면 반드시 잘못된 데이터를 저장하십시오.하지만 나중에 이 데이터를 우편물, 인구 통계 보고서 등에 사용할 수도 있다는 점에 유의하세요.데이터가 유효하지 않은 경우 사후에 수정하는 것이 쉽지 않습니다.

내 블로그 게시물은 다음과 같습니다.

http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html

또한 "Where StreetAddress Like '%whatever%'" 검색과 관련하여.자신의 이익을 위해 빠른 검색을 수행하는 경우에는 모두 훌륭하고 좋지만 주소 데이터에 의존하는 시스템 부분을 자동화하거나 중복 항목을 삭제하려고 시도하는 경우 사용자에게 자동 제안 등을 제공하십시오. 등의 경우 주소 테이블이 커질수록 사용할 수 없게 될 정도로 성능이 저하됩니다.

잘못된 주소가 회사에 실제 현금 비용을 초래할 염려가 없다면 문제가 되지 않습니다. 그러나 재정적으로 유익한(또는 미래에 있을 가능성이 있는) 용도로 주소를 사용하지 않는 경우에는 문제가 되지 않습니다. , 그렇다면 애초에 왜 그 정보를 저장하고 있습니까?

@스노퍼스 아, 당신은 대초원에 있어야합니다.내 블로그 게시물에 토지 설명에 대한 게시물을 포함하는 것을 간과했지만 나중에 게시물로 고려하고 있습니다.

법적 구획(LSD)은 앨버타, 서스캐처원, 매니토바의 석유 및 가스 및 기타 1차 자원 산업에서 주로 사용됩니다.또한 그렇게 널리 사용되지도 않습니다.)모두 동일한 형식을 사용합니다.섹션, 타운십, 범위, 자오선.예를 들어:

남동 28-12-17-W5

이것은 5번째 자오선 서쪽의 섹션 28, 타운십 12, 범위 17의 남동쪽 모퉁이입니다.

단일 필드를 사용하여 정규식으로 구문 분석하거나 LSD 분석을 포함하는 별도의 필드로 나눌 수 있습니다.SQL Server에서 정규식을 실행하는 것은 성능 측면에서 어려울 수 있습니다.이에 대한 나의 견해는 일반적인 주소 데이터와 동일합니다. 왜냐하면 각 데이터 조각은 별도의 필드에 저장되어야 하는 별도의 고유한 데이터 조각이기 때문입니다.그러나 이러한 유형의 주소 데이터의 대부분은 다음과 같습니다. ~ 아니다 거리 주소 대신 일반 대중이 사용하는 경우, 이 정보를 기본 주소 데이터와 분리(그러나 연결)할 수 있는 무언가를 설계하는 것이 좋습니다.그러나 토지 설명/LSD도 모든 캐나다 주소의 일부라는 점을 감안할 때 데이터베이스의 대상 고객에 따라 이를 내 기본 주소 테이블에 저장하고 싶은 유혹을 받을 수 있습니다.

다음은 앨버타 토지 자원 시스템의 붕괴에 대한 게시물입니다.

http://www1.agric.gov.ab.ca/%24department/deptdocs.nsf/all/agdex10302

적어도 석유 및 가스 분야에서 자주 발견할 수 있는 한 가지는(내 경험의 대부분이 여기에서 비롯됨) 작업자가 LSD의 처음 두 부분만 참조하는 경우가 많다는 것입니다.12개 중 28개 또는 16개 중 43개입니다.LSD의 나머지 부분은 주소의 지역성에 의해 암시됩니다.그랜드 프레리, 폭스 크릭, 울프 레이크 등

다른 팁

응용 프로그램이 배치되고 변경에 대한 지속적인 요청이 시작될 때까지 그것이 좋은 생각이라고 생각했습니다. 당시 저는 캐나다 온타리오에 살았으며 표준 주소가 어떻게 생겼는지 알았습니다. 일부 고객이 PO Box와 거리 주소를 결합한 주소를 하나로 묶을 때까지. 그런 다음 앨버타 고객은 다른 답변에 언급 된 구조화 된 코드를 사용하기 시작했습니다. 그런 다음 브리티시 컬럼비아는 거리 나 거리 번호가 없었던 곳, 부지, 구획 및 농촌 경로가있는 곳에 있습니다. C4, S16 RR7 Mountainville. 그리고 미국 공급 업체와 함께 우편 번호 규칙이 나왔습니다. 그리고 가끔 영국 고객이 데이터베이스에 나타 났으며 주소에 대해 알고 있다고 생각한 모든 것이 창 밖으로 나옵니다. 거리 번호가없는 건물 이름, 2 개의 거리 이름, 2 개의 마을 이름이 모두 하나의 주소로!

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

그것은 구성된 예이지만 존재합니다. 영국은 모든 현지 회사에 최신 국가 주소 데이터베이스가 있고 필요한 것은 우편 번호 및 주택 이름 또는 번호가 있기 때문에 관리합니다. 나머지는 데이터베이스에서 채워집니다.

그 주소의 경우, 아마도 다른 웨이버 초승달이있을 것입니다. 그리고 Norton-Norton은 오랫동안 Banbury 마을에 통합 된 마을 이었으므로 두 이름 모두 주소에 있습니다. 영국의 주소에서는 종종 존재하지 않는 지방 자치 단체를 얻습니다. 그들은 우편 시스템 내에만 존재한다는 점에서 우편 도시로 간주됩니다. 일반적으로 이름의 역사적 근거가 있습니다. 많은 런던 주소는 런던을 한 번에 쓰는 사람들과 Leyton 또는 South Ruislip 또는 Hillingdon과 함께 있습니다. 편지는 모두 즉시 전달됩니다.

따라서 소프트웨어의 기능이 시스템에 대한 외국 주소 항목을 방지한다는 것이 아니라면 그렇게하지 마십시오!

그건 그렇고, 당신은 같은 거리에있는 모든 사람들을 거리 이름으로 식별하는 것을 언급했습니다. 길거리 이름이있는 곳에서 덴버 콜로라도를 확인한 적이 있습니까? 나는 한때 Littleton (Denver Suburb)에서 길을 잃었습니다. 다른 주소를 찾으려고 다른 주소를 찾으려고 노력했습니다. 그런 다음 모든 도로에 둘 이상의 이름을 사용하는 영국의 관행이 있습니다. 예를 들어, Homerton Road가 있으며 Marsh Hill과 Homerton High Street와 Urswick Road와 Lower Clapton Road는 1 킬로미터 또는 2 킬로미터의 공간에 있습니다. 더 일반적으로, Wick 마을에는 Norton 도로가있을 것입니다. 당신이 그것을 따르면, 1 마일 또는 2 마일 후에 당신은 이제 Wick Road에 있고 Norton 마을에 들어오고 있음을 알 것입니다.

제 생각에는이 작업을 수행하는 데 약간의 이점이 있지만, 내가 시도한 모든 경우에,이를 수행하는 데 드는 비용과 복잡성은 무시할만한 이점을 능가합니다.

문제의 최소한 문제는 사용자가 일관된 형식으로 구성하고 주소를 다루는 모든 다른 부분을 입력하기 위해 제공하는 모든 별도의 분야를 존중하도록 교육/강요하는 것입니다. 대부분의 사람들은 거리 주소를 생각하지 않습니다. 최대 5 개의 다른 부품으로 구성되며 아마도 평소처럼 물건에 들어갈 수 있습니다.

따라서 사람들이 실제로 시스템을 사용하려고하지 않았다면 아마도 좋은 생각 일 것입니다.

유럽에서 거리 주소는 일반적으로 이름과 "숫자"입니다 (여기서 숫자는 "3A"와 같은 것일 수 있음). 하나의 이유로 별도로 저장하는 데이터베이스를 보았습니다. 공식 데이터베이스에서 거리 이름을 찾아 오타를 보호하기 위해 확인할 수 있습니다 (예 : 오타를 보호하기 위해). 따라서이 사용 사례의 경우 검증 가능성과 비 검사 부품을 다른 열에 유지하는 것이 합리적입니다.

나는 당신이 정보를 잃을 수 있다는 퍼지 두려움을 제외하고는 그것을 더욱 세분화 할 이유를 찾을 수 있다고 의심합니다.

전체 도메인을 모델링하기위한 객체 지향적 접근법을 따르고있는 경우 이점입니다. 귀하의 질문은이 블로그 제목을 상기시켜줍니다행진은 숫자가 아닙니다 답으로. 아날로그는 거리와 주소에 대해 말할 수 있습니다 ( "거리는 끈이 아닙니다"). Snorfus는 그의 의견에 대한 유효한 문제를 지적합니다.

주소의 각 구성 요소를 독립적으로 저장하는 데있어 장점이 될 수 있지만 비즈니스 요구 및 요구 사항에 대한 비용을 평가해야합니다. 우편 또는 배송과 관련된 일을하지 않으면 과잉이 될 수 있으며 아키텍처의 측면을 크게 복잡하게 만들 수 있습니다. 또한 코드에서 작동하는 다른 사람은 무슨 일이 일어나고 있는지 이해하지 못하고 실현하지 않고 중요한 문제를 일으켜 데이터베이스를 손상시킬 수 있습니다.

예를 들어, 미국 내에서 다음은 거리의 "배달 라인"입니다 : PO Box 12345.

이 경우 "PO Box"는 실제로 거리 이름이고 12345는 기본 번호입니다. 정상적인 "서식"과 기존의 지혜는 "123 Main Street"에서와 같이 주소가 먼저 기본 번호가 나열되어야 함을 시사합니다.

주소를 표준 방식으로 함께 형식화하는 경우 주소가 원래 어떻게 보이는지 기억해야합니다.

이곳은 주소 확인 및 표준화가 나오는 곳입니다. 적어도 미국과 영국을 포함한 몇몇 다른 국가에서는 주소를 온라인 주소 확인 서비스에 제출할 수있는 이점이 있습니다. 주소를 확인하십시오. 종종,이 서비스는 주소의 구성 요소 부분뿐만 아니라 메일 조각에 나타나야하는 주소를 돌려줍니다. 구성 요소에 대한 비즈니스 요구 사항이있는 경우 독립적으로 저장할 수 있습니다. 그렇지 않으면 주소 확인 웹 서비스에 대한 또 다른 호출은 원하는 시간에 구성 요소를 다시 산출해야합니다.

완전한 공개를 위해 나는 SmartyStreets의 창립자입니다. 우리는 우리에게 기반을 제공합니다 주소 확인 서비스가 포함됩니다 CASS 인증 검증 당신의 주소의. 당신은 당신이 가진 질문이 있으면 개인적으로 저에게 연락하는 것을 환영합니다.

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

제휴하지 않습니다 StackOverflow