Jakie problemy rozwiązuje się, dzieląc adresy ulic na poszczególne kolumny?

Mamy zespół, który projektuje tabele i relacje dla programistów. W naszej organizacji ściśle przestrzegają normalizacji 3NF - co, szczerze mówiąc, zgadzam się z tym, biorąc pod uwagę wielkość naszej organizacji i zmiany potrzeb lub klientów w czasie. Jest tylko jedna dziedzina, dla której nie mam jasności co do powodów ich decyzji projektowej: adresy.

Chociaż dotyczy to głównie adresów w Stanach Zjednoczonych, myślę, że może to dotyczyć każdego kraju, który to robi. Każda część adresu otrzymuje własną kolumnę w tabeli adresów. Weźmy na przykład ten adres w Stanach Zjednoczonych:

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

Zostałby podzielony w bazie danych w następujący sposób:

• Numer ulicy: 485
• Ułamek uliczny: 1/2
• Ulica jednokierunkowa: N (północ)
• Nazwa ulicy: Smith
• Typ ulicy: ST (ulica)
• Ulica post-kierunkowa: SW (Southwest)
• Miasto: Chicago
• Stan: IL (Illinois)
• Kod pocztowy: 11111
• Kod pocztowy: 2222
• Kraj (przyjmuje się, że jest to USA)
• Uwaga: Jane Doe
• Skrytka pocztowa: NULL
• Rodzaj mieszkania: APT (Apartament)
• Numer mieszkania: 300B

I byłoby jeszcze kilka innych kolumn związanych z trasami wiejskimi i trasami kontraktowymi. Ponadto nasza konkretna aplikacja będzie prawdopodobnie zawierać kilka międzynarodowych adresów. Projektanci danych powiedzieli, że dodają kolumny specyficzne dla adresów międzynarodowych, które byłyby normalnymi polami linii 1, linii 2.

Na początku myślałem, że to za DROGA. Wyszukiwanie online wielokrotnie odnosi się do korzystania z wiersza adresu 1, 2, 3 i ewentualnie 4, a następnie podziału miasta, regionu i kodu pocztowego. Mamy jeden przypadek użycia dla naszej nowej aplikacji, w której ta szczegółowość jest korzystna. Musimy sprawdzić, czy użytkownik nie tworzy duplikatu firmy, a sprawdzenie adresu jest jedną z weryfikacji. My może zmusić go do pracy w wierszu adresu 1 i 2, ale byłoby trudniejsze.

Jeśli chodzi o naszą konkretną aplikację, musimy przechowywać wiele rodzajów adresów dla firm i osób (adres fizyczny, mailing, wysyłka itp.). My może trzeba wygenerować druku listów, jednak wymóg ten nie został omówiony tak daleko.

Niektóre inne rzeczy, które aplikacje w naszej organizacji muszą obsługiwać:

• Audyt (z pełnymi tabelami historii)
• Drukowanie etykiet adresowych
• Generowanie formularzy drukowanych
• Raportowanie (dla rządów krajowych i regionalnych)

Chociaż nasza aplikacja może nie robić wszystkiego, co robi każda inna aplikacja, dzielenie adresów na wiele komponentów to standard korporacyjny, w którym pracuję. Niezależnie od tego, czy nasza aplikacja skorzystałaby na tym, jesteśmy do tego zmuszeni.

Częściowo powiązane pytanie StackOverflow: Gdzie jest dobry parser adresów, który został zamknięty, ale ilustruje, jak trudne mogą być parsowanie adresów.

Aby lepiej zrozumieć ich decyzję projektową i sprzedać naszemu klientowi pomysł ...

Jakie problemy rozwiązuje się, dzieląc adres ulicy na poszczególne kolumny?

Punkty bonusowe dla każdego, kto wdrożył taki system, ponieważ napotkał problemy.

Problemy, które można rozwiązać przez podział, obejmują

Walidacja Każdą część nazwy można porównać do listy głównej. Te, które nie pasują, mogą zostać odrzucone. Kod pocztowy / kod pocztowy jest oczywistym przykładem. Są one wydawane i utrzymywane przez niezależny organ. Jedyne prawidłowe są wydane przez ten organ.

Sortowanie i selekcja Widziałem przypadki, w których opłaty pocztowe są zmniejszane, jeśli poczta jest przekazywana do już zorganizowanej usługi dostarczania. Posiadanie odpowiednich kolumn daje namacalną wartość biznesową.

Analiza Przydatna może być wiedza o tym, dokąd zmierzają Twoje zamówienia, w geograficznie hierarchiczny sposób. Może to stymulować inicjatywy sprzedażowe, rozwój produktu lub płatności prowizyjne itp.

Duplikacja kodu Dzięki temu, że wszystkie aplikacje w organizacji przyjmują ten sam model danych (model najbardziej złożonego konsumenta), jedną bazę kodu można zastosować w całym przedsiębiorstwie i zachować spójność. Niekończącego się powielania włosów można uniknąć lub przynajmniej przekazać je głowicom śmigła. Adresy znajdujące się w różnych częściach organizacji mogą być stale aktualizowane. Obsługa klienta i satysfakcja mogą zostać zwiększone. Wysiłki rozwojowe mogą koncentrować się na unikatowych częściach systemu o wysokiej wartości.

Kwestie prawne Przepisy prawne i podatki różnią się w zależności od jurysdykcji. Dzięki osobnemu rejestrowaniu szczegółowych wartości adresów łatwiej jest odnieść dane transakcyjne do wymagań zgodności.

Duplikacja Łatwo jest sfałszować adresy przechowywane jako tekst, przenosząc jeden element do następnego wiersza lub zmieniając kolejność niektórych części. W pełni przeanalizowane adresy są łatwiejsze do porównania. Może to być zwykły problem z jakością danych lub może mieć wpływ na zgodność lub zgodność kredytową, jeśli powiedzmy, że wiele firm-muszów składa duże zamówienia pod ten sam adres dostawy lub karta kredytowa jest używana do dostarczania do wielu rozproszonych lokalizacji w krótkim okresie.

Formatowanie Części przechowywane osobno można łączyć w dowolny sposób odpowiadający aktualnym potrzebom. Jeśli, powiedzmy, długie cienkie etykiety z nadrukiem staną się tanie, możesz sformatować je, aby ich użyć.

Oczywiście żadne z nich nie może dotyczyć konkretnego zastosowania. Dane tego typu są znacznie łatwiejsze do przeanalizowania i zweryfikowania u źródła, gdy są gromadzone, niż kiedykolwiek będą w analizie końcowej. Tak więc, nawet jeśli YAGNI, lepiej może postawić dodatkowy wysiłek z góry przy niewielkich kosztach i potencjalnie dużych oszczędnościach w przyszłości.

Wreszcie nie odrzuciłbym czynnika ludzkiego. Model danych jest wytwarzany przez modelarzy danych. Tak robią. To ich zawód. Nie powiedzą ci, żebyś po prostu zrzucił to do BLOBA, prawda?

Spędziłem 7 lat opracowując oprogramowanie dla firmy wydawniczej, a jednym z najtrudniejszych problemów, jakie kiedykolwiek rozwiązaliśmy, było analizowanie adresów ulic na listach subskrypcyjnych. Przydatne jest dzielenie adresów na odrębne pola, ale NIGDY nie można NIGDY zaprojektować dla każdej możliwej patologicznej aberracji formatów adresów i komponentów, jakie ludzki mózg może opracować.

Każda miejscowość może mieć swoje dziwactwa, i to tylko w USA. Rzucanie w innych krajach i rzeczy stają się niemożliwe do zarządzania bardzo szybko dla każdego podejścia, które chce przeanalizować każdy adres. Tylko dwa przykłady:

W Hiszpanii numer ulicy zawsze występuje po nazwie ulicy i przecinku, a wiele adresów zawiera numer porządkowy piętra, taki jak 1 ° lub 3ª, wraz ze skrótami dla „lewej” („Izda” oznacza lewe drzwi po wchodzisz po schodach), „w prawo” („Dcha”) lub inne możliwości. Teraz pomnóż to dziwactwo przez liczbę różnych krajów i obszarów o różnych historycznych zwyczajach dotyczących adresów ... (Japonia? Wiejska Anglia? Korea? Chiny?)

W Portland, OR, są osie NS i EW, które dzielą miasto na kwadraty NW, NE, SW i SE (jak również N „kwadrant”, ale ja dygresję). Ulice NS są numerowane przyrostowo na wschód i zachód od tej osi, a adresy na ulicach EW są podyktowane tym, że numer NS to „sto bloków” numeru (tzn. Dom przy ulicy EW między 11 a 12 aleją miałby numer jak 1123). Całkiem standardowe rzeczy dla adresów w USA.

Każdy więc często napotkasz adres portlandzkiego jak 0205 SW Nebraska św . Wiodące zero? WTF? Tam jest moja integerkolumna dla numeru domu.

Po ustawieniu siatki oś NS była definiowana przez rzekę Willamette. Wszystko na wschód od rzeki to NE lub SE, a na zachód od rzeki NW lub SW. Gdy miasto rosło na południe, natknęło się na niewygodny fakt, że rzeka meandruje na wschód, więc projektując oś południe, masz problematyczny obszar, który znajduje się po „zachodniej” stronie rzeki, ale na wschód od osi. Rozwiązaniem było dodanie wiodącego zera, w efekcie znaku minus , z liczbami rosnącymi w kierunku wschodnim od linii osi.

Gdybym był tobą, porzuciłbym nadzieję na zaprojektowanie najlepszego systemu. Nie możesz zaspokoić wszystkich możliwości, a nowe zostaną stworzone, gdy ludzkość popycha się do wcześniej niezagospodarowanej ziemi.

W przypadku adresów w USA spójrz na to, co USPS już zrobiło w zakresie standaryzacji adresów, i pamiętaj, aby zrobić house_numberkolumnę a varchar. Podczas gdy jesteś na to dowiedzieć się, jak masz zamiar analizować 1634 PL Fort Lane Ave .

Dla reszty świata prawdopodobnie starałbym się wyodrębnić dodatkowe pola, aby pokryć 80-90% tego, co może się wydarzyć, i dostarczyć zestaw nieinterpretowanych pól, które mogą obsłużyć wszystko inne, gdy zajdzie taka potrzeba. To znaczy, jeśli twój parser nie obsługuje adresu, zapisz go bez analizy i oznacz jako taki. Jeśli uda Ci się przeanalizować adres, pamiętaj o kolejności, w jakiej znalazłeś różne pola, abyś mógł ponownie złożyć go w coś dostarczalnego.

Chciałem powiedzieć, że najważniejszym polem będzie kod pocztowy, ale w wielu miejscach to nie jest dane .

Powodzenia. Może to być zabawne i bardzo frustrujące przedsięwzięcie, ale kluczem do rozsądku jest wiedzieć, kiedy przestać próbować i po prostu zapisać dane wejściowe bez analizy lub częściowo przeanalizować z oryginalną danymi jako kopię zapasową.

Jak wszystkie pytania projektowe, istnieje niezwykle wykwalifikowany „to zależy”. To zależy od twojej historii danych - w jaki sposób dane są gromadzone, jak są wykorzystywane, jak są aktualizowane itp. Wszystkie moje komentarze powinny być traktowane jako punkty dyskusji, a nie odpowiedzi.

Wygląda na to, że * możesz skorzystać z usługi sprawdzania poprawności adresu, niż próbować zbudować ją dla siebie. Choć są one kosztowne, wiele takich usług oferuje znaczące zniżki na wysyłkę.

Oczywiście w przypadku niektórych historii danych istnieje kompromis. Możesz zachować przeanalizowane fragmenty adresu i utworzyć obliczoną kolumnę (prawdopodobnie zestaw kolumn) dla połączonego adresu. To jest odpowiedź na implementację, z sugerowanymi wszystkimi normalnymi zastrzeżeniami.

Wdrożyłem parsowany projekt adresu. Absolutnie potrzebowaliśmy tego ze względu na jakość danych i potrzeby przetwarzania danych. Ale to była firma, która miała adresy fizyczne, adresy pocztowe, adresy wirtualne itp.

Inną kwestią, która może się pojawić, jest to, że różne usługi pocztowe wymagają przedstawienia tych samych informacji w różnych formatach / zamówieniach / itp. Tak więc wymodelowanie części pozwala na prezentowanie tych samych informacji w różnych formatach i układach.

Wreszcie, nie musisz mieć operacji międzynarodowych, aby obsługiwać dane międzynarodowe. Nawet firmy z USA muszą obsługiwać adresy międzynarodowe. Zakładanie, że nigdy tego nie będziesz mieć, to ogromny błąd w danych. Klienci przenoszą się, dostawcy zmieniają siedzibę główną, dane kontaktowe dostawcy mogą być międzynarodowe, nawet jeśli mają siedzibę w USA. Nawet jeśli twój obecny system popełnił ten błąd, nie chcesz go kontynuować.

Bardzo polecam pisma i blogowanie Grahama Rhinda. Jest ekspertem w dziedzinie danych o wszelkiego rodzaju adresach i związanych z nimi kompromisach.

_{* Wszystko, co powiedziałem tutaj, to rażące uogólnienie. Jest tak wiele pytań, na które muszę znaleźć rozwiązanie projektowe, że rozmowa może potrwać kilka godzin. Prawdopodobnie niektóre zdjęcia i niektóre profile danych. A potem wiele naprawdę dziwacznych historii dotyczących adresów.}

Pomijając ogromne wyzwanie, jakim jest prawidłowe analizowanie nieprzewidywalnego bełkotu, który dostarczają ludzie, zaletą analizy jest to, że daje wymiary do grupowania i sortowania. Na przykład kod pocztowy. Jednak parsowanie określonego wymiaru nie przynosi żadnej korzyści, dopóki nie będzie konieczne grupowanie lub sortowanie według tego wymiaru.

Co to w ogóle jest adres? Możesz zrobić dobry przypadek, że jest to identyfikator lokalizacji, ale równie dobrze możesz zrobić, że to instrukcje dostawy - „W dół ulicy od fabryki cementu”. W Australii ludzie myślą, że kody pocztowe to identyfikatory lokalizacji, ale tak nie jest, to kody routingu - instrukcje dostawy. 4702 to Rockhampton Mail Centre, główny węzeł dystrybucyjny obsługujący region rozciągający się od morza do Emerald, górniczego miasta położonego 300 km w głąb lądu.

Jeśli chcesz zidentyfikować lokalizacje, Bing i Google mogą geokodować bezpośrednio z nieprzetworzonego ciągu na współrzędne GPS, które mogą być przechowywane w małej, prostej tabeli wraz z niepodzielonym ciągiem. Stosują jedyne ogólne podejście z dowolną szansą na niezmiennie dobre wyniki: częściowe ważenie rankingowe z kolosalną bazą danych potwierdzonych wyników.

Jeśli potrzebujesz instrukcji dostawy, nadal dobrze jest zachować nieprzetworzony ciąg, ponieważ może on zawierać wszystko .

Zauważ, że w obu przypadkach zaleciłem zachowanie nieprzetworzonego ciągu. To jest ponieważ

• jest użyteczny sam w sobie
• pewnego dnia wymyślisz, jak to przeanalizować
• kilka dni później dowiesz się, jak poprawnie parsować
• to się nigdy nie kończy

Prawdopodobnie adres to zawsze instrukcja dostawy, zawierająca co najmniej jeden identyfikator lokalizacji. List skierowany do „123 Main st, Emerald 4702” koduje trzy lokalizacje: RMC w północnej części Rockhampton, Emerald i adres. Urząd pocztowy Rockhampton wyśle ​​go po prostu do RMC. RMC wyśle ​​go na pocztę Emerald, a Emerald ma nadzieję, że wie, gdzie znaleźć 123 Main street.

Wcześniej wdrożyłem taki system, choć w Holandii. Chodzi o to, że tego rodzaju informacje mogą się zmieniać na więcej sposobów niż myślisz. Ulice zmieniają nazwy, miasta są scalane i tak dalej. Miło jest móc aktualizować tego rodzaju informacje bez parsowania adresów jako pojedynczego ciągu.

Rozróżnienie kodu pocztowego / kodu pocztowego, nazwy budynku i nazwy drogi może mieć sens. Ale kiedy zaczynasz dodawać „miasto”, „obszar” itp., Staje się to wątpliwe w porównaniu z samą linią 1, linią 2 itd. Problem polega na tym, że nawet ja i moja żona nie możemy ustalić nazwy miasta, w którym mieszkamy! Czy nazwa „wioski” ma być umieszczona w polu miasta, czy też znajduje się w linii pod nazwą drogi, a lokalne miasto jest umieszczone w polu miasta? (Niektórzy ludzie obrażają się, jeśli dzwonią tam, gdzie mieszkają wioski zamiast miasta, inni mieszkają w tym samym miejscu obrażają się, jeśli nazywają to miastem zamiast wioski!)

Dlatego próba zrobienia czegokolwiek wymyślnego nie jest lepsza niż używany system weryfikacji adresu. Ale robi się jeszcze gorzej. W Wielkiej Brytanii WSZYSTKIE adresy powinny mieć kod pocztowy, ale kod pocztowy nie jest przydzielany, dopóki jakiś czas po wybudowaniu domu …… Więc system musi pozwolić na złamanie każdej reguły dotyczącej adresu!

Oprócz problemów wspomnianych już w innych odpowiedziach, w niektórych językach - w szczególności germańskich - nazwy ulic są często złożone. Na przykład w wielu niemieckich miastach często znajduje się ulica „Bahnhofstrasse”, która prowadzi do dworca kolejowego („Bahnhof” oznacza dworzec kolejowy / kolejowy, „Strasse” oznacza ulicę). Z pewnością możesz oddzielić te dwa elementy, ale teraz, jeśli chcesz je ponownie złożyć (programowo), masz pytania o deklinację.

Lub w językach romańskich lub łacińskich często masz nazwy ulic w postaci „Rue de la Pais” lub „Boulevard des Champs-Élysées”. Teraz masz przyimek („de”) i określony artykuł („le” lub „la”) w miksie - i można je łączyć. Czy reprezentują część typu ulicy lub nazwy ulicy? (Prawdopodobnie musisz je gdzieś przechowywać, w przeciwnym razie znów zaczniesz się deklinować).

Kiedyś modelowałem coś takiego. Była to jednak bardzo niewielka aplikacja dla biura utrzymania nieruchomości mieszkalnych średniej wielkości uniwersytetu (w USA). Uczyniłem adresy bardzo szczegółowymi z następujących powodów:

• W okolicy znajdowały się ulice o tej samej nazwie, ale z innym „typem” ulicy (np. „Woods Avenue” vs „Woods Court”).
• Użytkownicy chcieli móc zoptymalizować prace konserwacyjne, np. Jeśli w tym samym bloku były dwa lub więcej zleceń serwisowych, można je obsłużyć w tym samym czasie.
• Użytkownicy chcieli mieć możliwość korelowania problemów między różnymi jednostkami (mieszkaniami) w tym samym budynku - np. Jeśli więcej niż jedno mieszkanie zgłosiło niskie temperatury lub niewystarczająco ciepłą wodę.

... i inne powody, których już nie pamiętam. (To było pod koniec lat 80.)

I znowu, miało to sens tylko dlatego, że istniała stosunkowo niewielka liczba adresów (i reguł formatowania adresów) do rozwiązania. Nie sądzę, aby to podejście miało skalę, nawet jeśli ogranicza się do adresów w USA, z powodów podanych już w innych odpowiedziach.