Muszę przechowywać kody pocztowe w bazie danych. Jak duża powinna być kolumna?

103

Oczekuję, że kolumna będzie VARCHAR2 w mojej bazie danych Oracle.

Amerykańskie suwaki to 9.

Kanadyjczyk ma 7 lat.

Myślę, że 32 znaki to rozsądny górny limit

czego mi brakuje?

[EDYTUJ] TIL: 12 to rozsądna odpowiedź na pytanie Dziękujemy wszystkim, którzy wnieśli swój wkład.

— EvilTeach
źródło

Przydatny link, jednak jego dokładność może być nieco ograniczona. EG podaje australijskie kody pocztowe jako 7 znaków, podczas gdy w rzeczywistości są to 4. Ref: en.wikipedia.org/wiki/Postcodes_in_Australia i lista kodów pocztowych dostępna na www1.auspost.com.au/postcodes .

— rossp

re: mój poprzedni komentarz - to nie znaczy, że ta lista nie jest przydatna jako przewodnik. Zakładając, że lista zawiera błędy po stronie dłuższych kodów pocztowych, najdłuższa długość to 9 znaków, więc 16 znaków lub mniej więcej powinno dać ci dużo miejsca do oddychania.

— rossp

Również lista krajów jest trochę krótka. Jestem pewien, że na świecie jest więcej krajów niż wymienionych ...

— Robert Koritnik,

2

Według en.wikipedia.org/wiki/List_of_postal_codes , najdłuższy jest 12 znaków, jeśli przechowujesz „-”, w przeciwnym razie 11

— Neil McGuigan

@CMS: Możesz zaktualizować link do tej strony Wikipedii , wygląda na bardziej szczegółową.

— Vajk Hermecz

51

Przeglądając stronę z kodami pocztowymi Wikipedii , 32 znaki powinny wystarczyć. Powiedziałbym, że nawet 16 znaków jest dobre.

— strager
źródło

8

Dobry link. Nawet uwzględniając interpunkcję w US ZIP + 4, 10 znaków wystarczyłoby dla każdego kraju, o ile wiem.

— Jonathan Leffler

Na podstawie tego linku, z powyższej strony,

— wybrałbym

5

Chile ma 7 znaków. Strona internetowa, do której się odwołałeś, po prostu pokazuje wariancję interpunkcyjną.

— EvilTeach

21

Jak już poruszył @ neil-mcguigan, wikipedia ma przyzwoitą stronę na ten temat. Na tej podstawie 12 znaków powinno to zrobić: http://en.wikipedia.org/wiki/List_of_postal_codes

Artykuł wikipedii wymienia ~ 254 krajów, co jest całkiem dobre, jeśli chodzi o UPU (Universal Postal Union), który ma 192 kraje członkowskie.

— Vajk Hermecz
źródło

2

Zauważ, że Montserrat to tylko 8 znaków, 1110-1350 oznacza zakres. discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Prawdopodobnie Wikipedia wymaga edycji, ponieważ podobnie wyglądający kod pocztowy dla Malty ma ogólny kod, taki jak „AAA NNNN”. Nie miałbym nic przeciwko, aby mieć nawet 15 znaków, ponieważ później może być mniejszy problem, jeśli będziemy musieli dostosować długość kolumny, również przy odpowiednim użyciu typów danych, i tak nie powinien on zajmować wszystkich 15 znaków (prawdopodobnie varchar lub nvarchar lub tak?) .

— Manohar Reddy Poreddy

12

Dlaczego miałbyś zadeklarować rozmiar pola większy niż rzeczywiste dane, które zamierzasz w nim przechowywać?

Jeśli początkowa wersja Twojej aplikacji ma obsługiwać adresy w Stanach Zjednoczonych i Kanadzie (co wynika z faktu, że w pytaniu podajesz te rozmiary), zadeklarowałbym to pole jako VARCHAR2 (9) (lub VARCHAR2 ( 10) jeśli zamierzasz przechowywać łącznik w polach ZIP + 4). Nawet patrząc na posty, które inni napisali dla kodów pocztowych w różnych krajach, VARCHAR2 (9) lub VARCHAR2 (10) wystarczyłoby dla większości, jeśli nie wszystkich innych krajów.

W dół linii możesz zawsze ZMIENIĆ kolumnę, aby zwiększyć długość, jeśli zajdzie taka potrzeba. Ale generalnie trudno jest powstrzymać kogoś, gdzieś przed podjęciem decyzji o „kreatywności” i umieszczeniu 50 znaków w polu VARCHAR2 (50) z tego czy innego powodu (tj. Dlatego, że chce innego wiersza na etykiecie wysyłkowej). Musisz także zająć się testowaniem przypadków granicznych (czy każda aplikacja wyświetlająca ZIP obsłuży 50 znaków?). A ponieważ klienci pobierają dane z bazy danych, zwykle przydzielają pamięć na podstawie maksymalnego rozmiaru pobieranych danych, a nie rzeczywistej długości danego wiersza. Prawdopodobnie nie jest to wielka sprawa w tym konkretnym przypadku, ale 40 bajtów na wiersz może być przyzwoitą ilością pamięci RAM w niektórych sytuacjach.

Nawiasem mówiąc, możesz również rozważyć oddzielne przechowywanie (przynajmniej w przypadku adresów w USA) kodu pocztowego i rozszerzenia +4. Generalnie przydatna jest możliwość generowania raportów według regionu geograficznego i często możesz chcieć umieścić wszystko w kodzie pocztowym razem, zamiast rozbijać go za pomocą rozszerzenia +4. W tym momencie nie trzeba próbować wypisywać pierwszych 5 znaków kodu pocztowego.

— Justin Cave
źródło

4

Cóż, zakładając, że kodujemy w czymś głupim, takim jak Pro * C, posiadanie pola wystarczająco dużego do wzrostu oznacza, że kod nie będzie musiał być dotykany, jeśli zwiększy się użycie.

— EvilTeach

Tak, podzielenie amerykańskiego kodu pocztowego na 5 i 4 cyfry może mieć sens, w zależności od tego, do czego zamierzasz go używać. Na przykład, jeśli robisz jakieś dopasowanie adresu, możesz najpierw dopasować do zip5 i rozwiązać niejednoznaczne sytuacje za pomocą zip 9. Pomaga również użyć kodu kraju

— EvilTeach

3

To, czego Ci brakuje, to powód, dla którego potrzebujesz specjalnego kodu pocztowego.

Jeśli naprawdę nie potrzebujesz PRACOWAĆ z kodem pocztowym, radzę się tym nie martwić. Przez pracę rozumiem specjalne przetwarzanie, a nie tylko drukowanie etykiet adresowych i tak dalej.

Po prostu utwórz trzy lub cztery pola adresowe VARCHAR2 (50) [na przykład] i pozwól użytkownikowi wprowadzić cokolwiek zechce.

Czy naprawdę potrzebujesz grupować zamówienia lub transakcje według kodu pocztowego? Myślę, że nie, ponieważ różne kraje mają bardzo różne schematy w tej dziedzinie.

— paxdiablo
źródło

Zgadzam się. Używając pola VARCHAR2, rzeczywistość jest taka, jak kod pocztowy, to naprawdę nie ma znaczenia. Nieco za duży jest lepszy niż denerwowanie jednego klienta, ponieważ nie może wprowadzić swoich danych.

— Toby Allen

Warchary są przydatne, ponieważ bazy danych (przynajmniej DB2) mogą optymalizować ich przechowywanie, aby nie marnować miejsca.

— paxdiablo

1

można zwrócić uwagę, że sortowanie według kraju i kodu pocztowego spowoduje w niektórych miejscach tańsze stawki pocztowe.

— EvilTeach

10

Disgaree. W pewnym momencie zdecydujesz, że będziesz musiał zweryfikować adresy w swojej bazie danych (np. W celu poprawienia błędów typograficznych i przy wprowadzaniu danych) i wtedy odkryjesz korzyść z prawidłowego skonstruowania modelu danych, zamiast po prostu wpychać wszystko wiadra.

— Gary Myers

1

@Pax Jeśli przekażesz przesyłkę masową do Royal Mail wstępnie posortowaną według głównego okręgu (pierwsza litera / dwie litery) kodu pocztowego, możesz ją dostarczyć za pośrednictwem MailSort, co jest tańsze niż zwykła poczta drugiej klasy. To tylko jeden przykład.

— Richard Gadsden,

3

Normalizacja? Kody pocztowe mogą być używane więcej niż raz i mogą być powiązane z nazwami ulic lub miast. Oddzielne tabele.

— Stephan Eggermont
źródło

Ciekawy. Inny punkt widzenia został po prostu odrzucony bez powodu. +1

— EvilTeach

Kod pocztowy zazwyczaj odnosi się do bloku po jednej stronie ulicy. Aby znaleźć szerszy region, należy wybrać pierwszą połowę kodu pocztowego. Umieszczenie tych informacji w osobnej tabeli naprawdę nic nie pomoże i byłoby bardziej skomplikowane w utrzymaniu.

— RevNoah

4

@EvilTeach: Założę się, że został odrzucony, ponieważ nie jest na temat. Czy mówi ci, jak duża powinna być kolumna, aby przechowywać każdy możliwy kod pocztowy na świecie? Nie.

— wmax

2

Kanadyjskie kody pocztowe składają się tylko z 6 znaków, w postaci liter i cyfr (LNLNLN)

— tegbains
źródło

3

Kanadyjskie kody pocztowe mają puste miejsce w środku „ANA NAN”, czyli 7 znaków.

— EvilTeach

1

Ale przestrzeń jest zawsze pośrodku, więc nie musisz jej przechowywać.

— Graeme Perrow

1

Spacja nie wydaje się być częścią danych: „Uwaga: kanadyjskie kody pocztowe są zawsze formatowane w tej samej kolejności: znak alfabetyczny / cyfra / alfabet / cyfra / alfabet / cyfra (np. K1A0B1)”. To pochodzi ze strony internetowej Canada Post.

— tegbains

2

Nie sądzę, żeby pomijanie przestrzeni miało coś wspólnego z „normalizacją”. To tylko kwestia wyświetlania. Jak myślniki w numerach kont. Nie przechowywałbym go i nie polegałbym na nim do identyfikacji kanadyjskich kodów pocztowych zamiast pola CountryCode (int), które można indeksować. Oddzielenie warstwy danych i prezentacji to właściwy sposób.

— Sam,

2

Canada Post preferuje spację w kodzie pocztowym podczas adresowania kopert. Najlepiej przechowywać go w spacji i obsługiwać walidację przy wejściu.

— RevNoah

2

Wielka Brytania opublikowała standardy: Katalog standardów danych rządu Wielkiej Brytanii

Max 35 characters per line

Międzynarodowy adres pocztowy:

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

Długość brytyjskiego kodu pocztowego to:

Minimum 6 and Maximum 8 characters

— PodTech.io
źródło

1

Jeśli chcesz zintegrować kody pocztowe w bazie danych, najlepiej skorzystać z bazy danych geonames. Chociaż jest to trudne w użyciu i zrozumieniu, jest to największa geograficzna baza danych dostępna bezpłatnie dla użytkowników takich jak my.

Wszystkie inne takie bazy danych mają mniej więcej takie same dane i strukturę. Po prostu usuwają dodatkowe / zbędne informacje z bazy danych. Jeśli robisz to tylko dla systemów o niskim obciążeniu, korzystaj z ich bezpłatnych usług, limity są atrakcyjne i zapewniają łatwiejszy interfejs przy użyciu json i ajax. Możesz zobaczyć ograniczenia tutaj

Dla twojej informacji varchar (20) jest wystarczający do przechowywania kodów pocztowych

— Jay Kapasi
źródło