주소를 개별 열로 분할하면 어떤 문제가 해결됩니까?

소프트웨어 개발자를위한 테이블과 관계를 디자인하는 팀이 있습니다. 우리 조직에서는 3NF 정규화 시행에 대해 매우 엄격합니다. 솔직히 말해서 저는 조직의 규모와 시간이 지남에 따라 요구 사항이나 고객이 어떻게 변하는 지에 동의합니다. 디자인 결정의 이유에 대해 명확하지 않은 영역은 주소입니다.

이것은 주로 미국의 주소에 중점을 두지 만, 이것이 모든 국가에 적용될 수 있다고 생각합니다. 주소의 각 부분은 주소 테이블에서 자체 열을 가져옵니다. 예를 들어,이 거친 미국 주소를 사용하십시오

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

다음과 같이 데이터베이스에서 분할됩니다.

• 거리 번호 : 485
• 거리 비율 : 1/2
• 거리 사전 방향 : N (북)
• 거리 이름 : Smith
• 거리 유형 : ST (거리)
• 거리 방향 : SW (남서쪽)
• 도시 : 시카고
• 주 : IL (일리노이)
• 우편 번호 : 11111
• 우편 번호 : 2222
• 국가 (미국으로 가정)
• 주의 : Jane Doe
• 사서함 : NULL
• 주거 유형 : APT (아파트)
• 거주 번호 : 300B

그리고 농촌 노선과 계약 노선과 관련된 몇 가지 다른 열이있을 것입니다. 또한 특정 응용 프로그램에는 몇 개의 국제 주소가있을 수 있습니다. 데이터 모델러는 국제 주소에 특정한 열을 추가 할 것이라고 말했는데, 이는 일반 1 행, 2 행 필드입니다.

처음에 나는 이것이 선상에 있다고 생각했다. 온라인으로 반복해서 검색한다는 것은 주소 라인 1, 2, 3 및 4를 사용한 다음 도시, 지역 및 우편 번호를 분리하는 것입니다. 이 세분성이 유용한 새로운 응용 프로그램에 대한 하나의 유스 케이스가 있습니다. 사용자가 중복 비즈니스를 만들지 않는지 확인해야하며 주소 확인이 유효성 검사 중 하나입니다. 우리는 할 수 는 주소 라인 1과 2와 함께 작동하도록 얻을 수 있지만 더 어려울 것입니다.

특정 응용 프로그램의 경우 비즈니스 및 사람들을 위해 여러 종류의 주소 (물리적, 우편, 운송 등)를 저장해야합니다. 우리는 수 인쇄 양식 편지를 생성 할 필요가 있지만, 요구 사항은 지금까지 논의되지 않았습니다.

우리 조직의 응용 프로그램이 지원해야 할 다른 것들 :

• 감사 (전체 히스토리 테이블 사용)
• 우편 라벨 인쇄
• 인쇄 된 양식 생성
• 보고 (국가 및 지역 정부)

우리의 응용 프로그램이 다른 모든 응용 프로그램이 수행하는 모든 작업을 수행하지는 않지만 주소를 여러 구성 요소로 나누는 것이 내가 일하는 엔터프라이즈 표준 입니다. 우리의 응용 프로그램이 응용 프로그램의 이점을 얻을 수 있는지 여부에 관계없이 우리는이 작업을 수행해야합니다.

Semi Related StackOverflow question : 좋은 주소 파서는 어디에 있었지만 주소를 파싱하는 것이 얼마나 어려운지를 보여줍니다.

디자인 결정을 더 잘 이해하고 고객을 아이디어에 판매하기 위해 ...

주소를 개별 열로 분할하면 어떤 문제가 해결됩니까?

이와 같은 시스템을 구현 한 사람에게는 문제가 발생하여 보너스 포인트가 부여됩니다.

분할하여 해결할 수있는 문제는 다음과 같습니다.

유효성 검사 이름의 모든 부분을 마스터 목록과 비교할 수 있습니다. 일치하지 않는 것은 거부 할 수 있습니다. 우편 번호 / 우편 번호는 명백한 예입니다. 이들은 독립적 인 기관에 의해 발행되고 유지됩니다. 유일하게 유효한 것은 그 기관이 발행 한 것입니다.

분류 및 선택 이미 우편 서비스가 어느 정도 조직 된 배달 서비스로 전달되는 경우 우편 요금이 절감되는 경우를 보았습니다. 해당 열이 있으면 실질적인 비즈니스 가치가 창출됩니다.

분석 지리적으로 계층 적으로 주문이 어디로 가는지 아는 것이 유용 할 수 있습니다. 이는 판매 이니셔티브, 제품 개발 또는 수수료 지불 등을 유발할 수 있습니다.

코드 복제 조직의 모든 응용 프로그램이 동일한 데이터 모델 (가장 복잡한 소비자의 데이터 모델)을 채택함으로써 단일 코드 기반을 전사적으로 채택하고 일관성있게 유지할 수 있습니다. 끝없이 복제 된 모발 분리를 피하거나 적어도 프로펠러 헤드에 위임 할 수 있습니다. 조직의 다른 부분에서 보유한 주소를 일관되게 업데이트 할 수 있습니다. 고객 서비스 및 만족도를 높일 수 있습니다. 개발 노력은 시스템의 고유하고 가치가 높은 부분에 집중할 수 있습니다.

법적 문제 법률과 세금은 관할권에 따라 다릅니다. 자세한 주소 값을 별도로 캡처하면 트랜잭션 데이터를 규정 준수 요구 사항과 상호 참조하기가 더 쉽습니다.

복제 한 요소를 다음 줄로 이동하거나 일부를 다시 시퀀싱하여 텍스트로 유지되는 주소를 스푸핑하는 것은 간단합니다. 완전히 파싱 된 주소는 비교하기가 더 쉽습니다. 여러 개의 쉘 회사가 동일한 배송 주소로 대량 주문을하거나 신용 카드를 사용하여 단기간에 여러 분산 된 위치로 배송하는 경우 이는 단순한 데이터 품질 문제이거나 규정 준수 또는 신용에 영향을 미칠 수 있습니다.

포맷팅 개별적으로 보유 된 부품은 현재 요구에 맞는 방식으로 결합 할 수 있습니다. 예를 들어, 길고 얇은 인쇄 레이블이 저렴 해지면 다시 포맷하여 사용할 수 있습니다.

물론 이들 중 어느 것도 특정 응용 프로그램에 적용되지 않을 수 있습니다. 이 유형의 데이터는 수집 후 소스 분석 후보다 훨씬 쉽게 분석 및 검증 할 수 있습니다. 따라서 YAGNI가더라도 적은 비용과 큰 미래 절약을 위해 추가 노력을 기울이는 것이 좋습니다.

마지막으로, 나는 인적 요소를 무시하지 않을 것입니다. 데이터 모델은 데이터 모델러에 의해 생성됩니다. 그들이하는 일입니다. 그것이 그들의 직업입니다. 그들은 단지 BLOB에 그것을 덤프하라고 말하지 않을 것입니다.

7 년 동안 출판 회사를위한 소프트웨어를 개발하면서 가장 어려운 문제 중 하나는 구독 목록에서 주소를 파싱하는 것이 었습니다. 별개의 필드에 주소를 분할하는 데 유용하지만, 결코 이제까지 주소 형식과 인간의 뇌가 고안 수있는 구성 요소의 가능한 모든 병적 인 수차 설계합니다.

모든 지역에는 단점이있을 수 있으며 미국에만 있습니다. 다른 국가에 던져 버리면 모든 주소를 구문 분석하려는 모든 접근 방식에 대해 매우 빠르게 관리 할 수 ​​없게됩니다. 두 가지 예만 있습니다 :

스페인에서 거리 번호는 항상 거리 이름과 쉼표 뒤에옵니다. 많은 주소에는 1 ° 또는 3ª와 같은 층 번호 서수와 "왼쪽"( "Izda"는 왼쪽 뒤의 약어)과 같은 약어가 들어 있습니다. 계단을 올라가) "오른쪽"( "Dcha") 또는 다른 가능성. 이제 그 기발함을 주소에 대한 다른 역사적 관습을 가진 여러 나라와 지역의 수로 곱하십시오 ... (일본? 농촌 영국? 한국? 중국?)

오리건 주 포틀랜드에는 도시를 NW, NE, SW 및 SE 사분면 (N "사분면"뿐만 아니라 분산)으로 나누는 NS 및 EW 축이 있습니다. NS 거리는이 축에서 동쪽과 서쪽으로 점진적으로 번호가 매겨지고, EW 거리의 주소는 NS 거리 번호가 숫자의 "백 블록"에 의해 결정됩니다 (즉, EW 거리에있는 11 번과 12 번 도로 사이의 집은 숫자를 갖습니다) 같은 1123). 미국 주소를위한 매우 표준적인 것들.

너무 자주 0205 SW Nebraska St 와 같은 포틀랜드 주소로 연결 됩니다. 선행 제로? WTF? integer집 "번호"에 대한 열 이 있습니다 .

그리드가 설정되면 NS 축은 Willamette 강에 의해 정의되었습니다. 강 동쪽의 모든 것은 NE 또는 SE, 강 서쪽은 NW 또는 SW였습니다. 도시가 남쪽으로 자라면서 그들은 강이 동쪽으로 엉망이라는 불편한 사실에 부딪 쳤습니다. 따라서 남쪽 축을 투영하면 강의 "서쪽"쪽이지만 축의 동쪽에있는이 문제가있는 영역이 있습니다. 해결책은 축선에서 동쪽을 향하여 숫자가 증가 하는 선행 0을, 실제로 빼기 부호 를 추가하는 것 입니다.

내가 당신이라면 궁극의 시스템 설계에 대한 희망을 포기할 것입니다. 모든 가능성을 다룰 수는 없으며, 인류가 이전에 개발되지 않은 땅으로 밀려남에 따라 새로운 가능성이 만들어 질 것입니다.

미국 주소의 경우 USPS가 주소 표준화에서 이미 수행 한 작업을 살펴보고 house_number열을 a 로 만드십시오 varchar. 이 과정에서 1634 EN Fort Lane Ave 를 어떻게 파싱 할 것인지 파악하십시오 .

세계의 다른 지역에서는 아마도 앞으로 나올 가능성의 80-90 %를 커버하기 위해 추가 필드를 추상화하고 필요할 때 다른 모든 것을 처리 할 수있는 해석되지 않은 필드 세트를 제공하려고합니다. 즉, 파서가 주소를 처리하지 못하면 파싱하지 않고 저장하십시오. 주소를 구문 분석 할 수있는 경우 다양한 필드를 찾은 순서를 기억하여 전달 가능한 것으로 재 조립할 수 있도록하십시오.

가장 중요한 분야는 우편 번호가 될 것이지만 많은 곳에서 제공되지는 않습니다 .

행운을 빕니다. 이것은 재미 있고 매우 실망스러운 노력이 될 수 있지만, 정신 건강의 열쇠는 시도를 끝내고 입력을 구문 분석하지 않은 상태로 저장하거나 원래 입력으로 부분적으로 구문 분석 한 백업을 백업하는 것입니다.

모든 디자인 관련 질문과 마찬가지로, "자격이 있습니다". 데이터 스토리에 따라 다릅니다. 데이터 수집 방법, 사용 방법, 업데이트 방법 등 모든 의견은 방법이 아닌 토론 지점으로 간주해야합니다.

주소 확인 서비스를 사용하는 것보다 직접 주소 확인 서비스를 사용하면 더 많은 이점을 얻을 수 있습니다. 비용이 많이 들지만 이러한 많은 서비스에는 상당한 메일 할인이 제공됩니다.

물론 특정 데이터 스토리에 대해서는 절충안이 있습니다. 구문 분석 된 주소 조각을 유지하고 결합 된 주소에 대해 계산 열 (열 집합)을 만들 수 있습니다. 이것은 모든 일반적인주의 사항이 암시 된 구현 답변입니다.

파싱 ​​된 주소 디자인을 구현했습니다. 우리는 데이터 품질과 데이터 처리 요구를 위해 이것이 절대적으로 필요했습니다. 그러나 그것은 물리적 주소, 우편 주소, 가상 주소 등을 가진 사업이었습니다.

발생할 수있는 다른 문제는 우편 서비스마다 다른 정보가 다른 형식 / 주문 등으로 표시되어야한다는 것입니다. 따라서 부품을 모델링하면 동일한 정보를 다양한 형식과 레이아웃으로 표시 할 수 있습니다.

마지막으로 국제 데이터를 지원하기 위해 국제 비즈니스 운영이 필요하지 않습니다. 미국에 본사를 둔 기업들도 국제 주소를 지원해야합니다. 당신이 결코 그것을 가질 수 없다고 가정하는 것은 큰 데이터 실수입니다. 고객이 이동하고 공급 업체가 본사를 변경하며 공급 업체 연락처 정보는 미국 본사가 있더라도 국제적 일 수 있습니다. 현재의 시스템이 실수를하더라도이 시스템을 계속 진행하고 싶지는 않습니다.

Graham Rhind의 저술과 블로깅을 적극 권장합니다. 그는 모든 종류의 주소와 관련된 트레이드 오프에 관한 데이터 분야의 전문가입니다.

_{* 여기서 말한 것은 총 일반화입니다. 몇 시간의 채팅이 필요할 수있는 디자인 솔루션에 관한 많은 질문이 있습니다. 일부 사진 및 일부 데이터 프로파일 링도 가능합니다. 그리고 주소에 대한 정말 기발한 데이터 이야기가 많이 있습니다.}

사람들이 제공하는 예측할 수없는 횡설수설을 올바르게 파싱해야한다는 엄청난 도전을 완전히 버리고 이점 은 그룹화 및 정렬 차원을 제공한다는 것입니다. 예를 들어 우편 번호. 그러나 해당 차원을 그룹화하거나 정렬해야 할 때까지 특정 차원을 구문 분석하는 데 따른 결과 는 없습니다 .

뭐 어쨌든 주소 는 ? 위치 식별자 인 경우에는 좋은 사례를 만들 수 있지만 "시멘트 공장에서 길을 벗어난 곳"이라는 배달 지침도 마찬가지입니다. 호주에서 사람들은 우편 번호가 위치 식별자라고 생각하지만 라우팅 코드는 아닙니다. 4702는 Rockhampton Mail Centre로, 바다에서 300km 내륙의 광산 도시인 에메랄드에 이르는 지역을 서비스하는 주요 유통 노드입니다.

위치를 식별하려는 경우 Bing과 Google은 구문 분석되지 않은 문자열에서 GPS 좌표로 직접 지오 코딩 할 수 있으며 구문 분석되지 않은 문자열과 함께 작고 간단한 테이블에 저장할 수 있습니다. 그들은 일관되게 좋은 결과를 얻을 수있는 유일한 일반적인 접근법을 사용합니다 : 검증 된 결과의 거대한 데이터베이스와 순위 가중 부분 일치.

배달 지침을 원한다면 구문 분석되지 않은 문자열을 포함하는 것이 좋습니다.

두 경우 모두 구문 분석되지 않은 문자열을 유지하는 것이 좋습니다. 그것은 ~ 때문에

• 그것은 그 자체로 유용합니다
• 언젠가는 파싱하는 방법을 알아낼 것입니다
• 그 후 며칠 후에 올바르게 구문 분석하는 방법을 알아낼 것입니다.
• 이건 절대 끝나지 않아

틀림없이 주소는 항상 포함, 배달 지침 적어도 하나의 위치 식별자. "123 Main st, Emerald 4702"로 작성된 서신은 세 곳, 즉 록 햄프 턴 북쪽의 RMC, 에메랄드 및 주소를 인코딩합니다. Rockhampton 우체국은 간단히 RMC로 보냅니다. RMC는 그것을 에메랄드 우체국으로 보낼 것이며, 에메랄드 우체국은 123 Main Street를 찾을 수있는 곳을 잘 알고 있습니다.

비록 네덜란드에서도 이런 시스템을 구현했습니다. 문제는 이런 종류의 정보가 생각보다 많은 방식으로 변경 될 수 있다는 것입니다. 거리의 이름이 바뀌고 도시가 병합되는 등의 작업이 수행됩니다. 주소를 단일 문자열로 구문 분석하지 않고 이러한 종류의 정보를 업데이트 할 수있는 것이 좋습니다.

우편 번호, 우편 번호, 건물 이름, 도로 이름을 구분하는 것이 합리적입니다. 그러나 "town", "area"등을 추가하기 시작하면 line1, line2 등과 비교할 때 의심스러워집니다. 문제는 나와 아내가 우리가 사는 도시의 이름에 동의 할 수 없다는 것입니다! 마을 이름에 "마을"이라는 이름을 붙입니까, 아니면 도시 이름을 마을 이름에 붙인 상태에서 도로 이름 아래의 줄에 있습니까? (일부 사람들은 마을 대신 마을에서 사는 곳으로 전화하면 불쾌감을 느끼고, 같은 장소에 사는 다른 사람들은 마을 대신 마을로 불면 기분이 상하게됩니다!)

따라서 멋진 작업을 시도하는 것은 사용하는 주소 확인 시스템보다 낫지 않습니다. 그러나 더욱 악화됩니다. 영국에서는 모든 주소에 우편 번호가 있어야하지만, 집이 지어진 후 언젠가는 우편 번호가 할당되지 않습니다.

다른 답변에서 이미 언급 한 문제 외에도 일부 언어에서-특히 게르만어-거리 이름은 복합적인 경향이 있습니다. 예를 들어, 많은 독일 도시 / 도시에서 기차역으로가는 거리 인 "Bahnhofstrasse"(철도 / 기차를 의미하는 "Bahnhof", 거리를 의미하는 "Strasse")를 갖는 것이 일반적입니다. 확실히이 두 구성 요소를 분리 할 수는 있지만, 이제 프로그래밍 방식으로 다시 구성하려면 기울기 문제가 발생합니다.

또는 "로맨스"또는 라틴어 언어에서 "Rue de la Pais"또는 "Boulevard des Champs-Élysées"형식의 거리 이름을 자주 사용합니다. 이제 믹스에 전치사 ( "de")와 명확한 기사 ( "le"또는 "la")가 있으며 결합 될 수 있습니다. 거리 유형 또는 거리 이름의 일부를 나타 냅니까? (어쩌면 그것들을 어딘가에 저장해야합니다. 그렇지 않으면 다시 기울어집니다.)

한 번 이런 식으로 모델링했습니다. 그러나 중소 규모의 대학 (미국)의 주거용 부동산 유지 관리 사무소에는 매우 작은 응용 프로그램이었습니다. 다음과 같은 이유로 주소를 매우 세분화했습니다.

• 같은 이름이지만 다른 거리 "유형"(예 : "Woods Avenue"대 "Woods Court")의 거리가있었습니다.
• 사용자는 동일한 블록에 둘 이상의 서비스 요청이 동시에 처리 될 수있는 경우와 같이 유지 관리 작업을 최적화 할 수 있기를 원했습니다.
• 사용자는 같은 건물에서 여러 아파트 (아파트) 간의 문제를 서로 연관시킬 수 있기를 원했습니다 (예 : 둘 이상의 아파트가 추운 온도 또는 불충분 한 온수를보고 한 경우).

... 그리고 더 이상 기억하지 못하는 다른 이유들. (이것은 1980 년대 후반에있었습니다.)

다시 말하지만, 처리해야 할 주소 (및 주소 형식 규칙)가 상당히 적었 기 때문에이 방법은 의미가 있습니다. 나는 다른 접근법에서 이미 주어진 이유로 미국의 주소로 제한되어 있더라도이 접근법이 확장 될 것이라고 생각하지 않습니다.