Wie sollten internationale geografische Adressen in einer relationalen Datenbank gespeichert werden?

Question

Was ist angesichts der Aufgabe, internationale geografische Adressen in einer relationalen Tabelle zu speichern, das flexibelste Schema? Sollte jeder Teil der Adresse in seine eigenen Felder unterteilt werden, oder sollte es eher wie ein freier Text sein?

Gibt es einen Sinn bei der Trennung einer unterschiedlich formatierten Adresse in verschiedene Tabellen? Haben Sie beispielsweise eine Tabelle für USAAddress, Canadianaddress, Ukaddress ...?

Answer 1

Ich werde meine Gedanken aus meinem Blog -Beitrag zusammenfassen - Eine Lektion im Adressspeicher.

Bei meinem aktuellen Projekt [ich arbeite für ein Logistikunternehmen] speichern wir internationale Adressen. Ich habe in der Gestaltung dieses Teils der Datenbank über Adressen auf der ganzen Welt geforscht. Es gibt viele verschiedene Formate. In der westlichen Welt neigen wir dazu, ein ziemlich einheitliches Format zu verwenden - ein paar Unterschiede, aber sie sind meistens:

• Hausnummer - numerisch
• Haus- oder Gebäudename - [Varchar - In Großbritannien werden einige Häuser/Gebäude namentlich identifiziert, nicht nach Nummer
• Straßennummer -Suffix Varchar, obwohl in den meisten Fällen Char (1) ausreichen würde
  • A, B usw.
• Straßenname Varchar
• Straßenart Varchar oder int, wenn Sie einen Streettypes -Tisch haben
  • Bisher habe ich 262 einzigartige Typen in der englischsprachigen Welt gefunden, es gibt wahrscheinlich mehr und vergessen Sie nicht andere Sprachen, dh Strasse, Rue usw.
• Straßenrichtung Varchar (2)
  • N, E, S, W, Ne, Se, NW, SW
• Adresstyp Varchar oder int, wenn Sie eine adressTypes -Tabelle haben
  • Postfach
  • Wohnung
  • Gebäude
  • Boden
  • Büro
  • Suite
  • etc...
• Adresstypkennung Varchar
  • IE Boxnummer, Apartmentnummer, Bodennummer erinnern Apartmentnummern und Büros manchmal alphanumerische Informationen - wie 1a
• Lokale Gemeinde Varchar oder int, wenn Sie eine Gemeinden Tabelle haben
  • Zum Beispiel, wenn Ihr Hamlet/Dorf in der Adresse vor der Stadt erscheint.
• Stadt/Stadt Varchar oder int, wenn Sie eine Städte Tabelle haben
• Regierungsviertel Varchar oder int, wenn Sie eine Distrikttabelle haben
  • Staat (USA)
  • Provinz (Kanada)
  • Bundesbezirk (Mexiko)
  • Grafschaft (UK)
  • etc...
• Postbereich Varchar
  • Reißverschluss (USA)
  • Postleitzahl (Kanada, Mexiko)
  • Postleitzahl (UK)
• Land Varchar oder int, wenn Sie eine Länder Tabelle haben

Dies scheint die meisten Länder abzudecken, aber die Bestellung der Felder kann unterschiedlich angezeigt werden. Sie finden eine Liste von Anzeigformaten unter http://www.bitboost.com/ref/international-address-formats.html#formats

In vielen Ländern fällt beispielsweise die Postleitzahl vor dem Namen der Stadt und der Straßennummer nach dem Straßennamen. In Kanada, den USA und Großbritannien geht die Straßennummer dem Straßennamen voraus und die Postleitzahl (oder ZIP) kommt nach dem Stadtnamen.

Als Antwort auf Ihre Frage zur Trennung der Adressen in verschiedene Länder würde ich es nicht vorschlagen, dass es das Leben in anderen Bereichen nur schwerer machen wird - zum Beispiel berichten. Das Format, das ich bereitgestellt habe, deckt alle Adressen in unserer Logistikdatenbank ab, die die USA, Kanada, Mexiko und Großbritannien ohne Probleme abdeckt. Es deckt auch alle unsere europäischen, chinesischen, japanischen und malaysischen Adressen ab. Ich kann nicht für andere Länder sprechen, aber ich musste noch keine Adresse aus einem Land speichern, die diese Felder nicht unterstützen.

Ich schlage nicht vor Aufgrund von Fehlinformationen, Tippfehler, Rechtschreibfehlern usw. Wenn Sie Ihre Felder trennen, können Sie Entfernungsalgorithmen verwenden, um nach einer wahrscheinlichen Bedeutung zu überprüfen, die Wahrscheinlichkeit, den Straßennamen gegen Postleitzahl und Straßennummer zu überprüfen oder die Provinz und Stadt gegen Straßennamen usw. zu überprüfen. Versuchen Sie es mit dem Straßennamen usw. Wenn Sie etwas davon tun, wenn Sie eine Zeichenfolge haben, die Ihre gesamte Straßenadresse bezeichnet. Es ist keine triviale Angelegenheit durch irgendeine Fantasie.

QA in einer Adressdatenbank ist Kopfschmerz, Zeitraum. Der einfachste Weg, Ihr Leben in diesem Bereich zu vereinfachen, besteht darin, sicherzustellen, dass alle Felder nur eine einzige Informationen enthalten, die zum Zeitpunkt der Eintritt automatisch als korrekt überprüft werden kann. Wahrscheinlichkeit, Entfernungsalgorithmen und regelmäßige Ausdrücke können die Gültigkeit des Eintritts überprüfen und dem Benutzer Feedback geben, was ihr Fehler war und geeignete Korrekturen vorschlägt.

Eine Vorbehalt, die sich bewusst ist, sind Straßen mit Namen, die auch Street -Typen sind. Wenn Sie Kanada abdecken, müssen Sie sich der "Avenue Road" in Toronto bewusst sein, die Sie in großer Zeit stolpert, wenn Sie die Adresse1, 2 verwenden, 2, 2 , 3 Format. Dies tritt wahrscheinlich auch an anderen Orten auf, obwohl ich sie nicht bewusst bin - diese einzelne Instanz war genug für mich, um WTF zu schreien?!

Answer 2

Achten Sie darauf, dass Sie die Adressformate nicht überanalysieren. Wenn Sie dies tun, haben Sie sehr wahrscheinlich eine Spezifikation, die die meisten Benutzer arbeiten müssen um, sie effektiv zwingen, die falschen Felder zu verwenden oder nur die primären Felder zu füllen und die zusätzlichen Felder zu ignorieren.

Halten Sie die Dinge einfach.

Ein StreetType, wie von Benalabaster erwähnt, verursacht Probleme, wenn Sie mit Sprachen arbeiten, die sich als Sprachen wie Englisch oder Spanisch isolieren.

Um Ihnen zu zeigen, wie schlimm Dinge in freier Wildbahn kommen können: Die "Henriette Roland Holststraat" in Amsterdam, die aus "Henriette" + "Roland Holst" + "Straat" aufgebaut wurde, die als "Roland Holststraat" abgekürzt werden kann Roland Holststr. "Oder falsch geschrieben als" Hrholststr. " oder "Henriette Roland-Holst Straat", abhängig vom Wetter. Wenn Sie für jedes Land auf Erden ein aktuelles Straßenregister haben, werden Sie nirgendwo hin gehen.

Und schließlich achten Sie darauf, dass sich in einigen mehrsprachigen Ländern Namen von einer Sprache zu einer anderen unterscheiden können! Zum Beispiel in Brüssel, wo viele Straßen beide ein Französisch haben und Ein niederländischer Name: "Avenu du Port" und "Havenlaan", abhängig von der bevorzugten Sprache des Adressaten. (Google Maps zeigt beide Namen abwechselnd an, nur um auf der sicheren Seite zu sein.)

Sie können versuchen, hier alle Arten von cleveren Tricks zu entwickeln, sind aber die Vertriebsmitarbeiter. wirst du das verstehen?

Answer 3

Das hängt davon ab, was Sie damit machen möchten.

Ich habe festgestellt, dass es immer einfacher ist, Adressen für andere Zwecke zu verwenden (z. B. Überprüfung gegen USPS -Daten oder Versandraten von UPS/Fedex), wenn sie getrennt sind.

Folgendes verwende ich normalerweise für Adressen:

• Anschrift Zeile 1
• Adresszeile 2
• Adresszeile 3
• Stadt
• Region
• Postleitzahl
• Bezirk
• Land

Als Antwort auf die Bearbeitung: In den meisten Situationen sehe ich die Verwendung nicht. Die oben aufgeführte Tabelle, die oben aufgeführt ist, enthält genügend Felder (und ist generell genug) für die meisten Adressen des Landes.

Answer 4

Adresse

Als Polar gegenüber der hervorragenden Antwort @Benalabaster haben Sie einfach:

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

Ihre clientseitigen Formularlayouts können weiterhin so komplex sein, wie Sie es für Anpassung sehen (oder eine Multi-Line-Eingabe verwenden, bei der der Benutzer seine Adresse manuell eingeben kann). Sie können dann die Linienbrüche in der Adresse hinzufügen, falls erforderlich.

Land

Ihr Landtisch würde wie folgt aussehen:

country_code  VARCHAR(2)
country_name  VARCHAR(255)

Zusätzlich könnten Sie haben eines der folgenden:

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

Verwenden Sie dann die folgenden Listen, um Ihre Landtabelle zu entwerfen:

• Wikipedia: ISO 3166-1 Alpha-2
• Github: Länder ohne Postcodes
• Github: Mysql Country List
• Postcode Regex -Liste

Answer 5

Hier ist eine Anekdote für alle, die über diese Frage stolpern:

Ich spreche als eine Person, die viele Kontinente (Europa, Asien, Nordamerika) gelebt und gearbeitet hat. Nach meiner Erfahrung und der Erfahrung der Menschen, mit denen ich zusammenarbeite, war es für uns viel einfacher, Systeme zu verwenden, die Folgendes ausführen:

1. Geben Sie drei Zeilen an, in die ich eine Adresse eingeben werde. Geben Sie diese drei Zeilen an Ihren örtlichen Postdienst weiter, während ich sie tippe, wörtlich. Lassen Sie mich ein beliebiges Zeichensatz verwenden, den ich will; Verwenden Sie UTF-8 oder etwas Besseres.
2. Wenn Ihr System geschäftliche Anforderungen enthält, die mich benötigen, um bestimmte Informationen (z. B. Postleitzahl, Präfektur, Zustand usw.) anzugeben, fragen Sie diese separat darum. Mit geschäftlichen Anforderungen meine ich Dinge wie Analytics; Diese Informationen sollten nicht an Ihren lokalen Postdienst weitergegeben werden (es sei denn, ich schreibe auch die gleichen Informationen in eine der drei Zeilen von Punkt 1 oben).
3. Haben Sie einen Dropdown, der mich auffordert, den kategorialen Standort der Adresse anzugeben, die ich in den oben genannten Zeilen von Punkt 1, vielleicht dem Land, angegeben habe.
4. Wenn Sie die Informationen analysieren müssen, die ich in den Zeilen von Punkt 1 angreife, verwenden Sie meine Antwort auf Punkt 3, um Regex auszuwählen. Führen Sie diesen Regex gegen die Informationen aus, um sie zu analysieren. Versuchen Sie, die Benutzeroberflächenelemente von Punkt 2 mithilfe der Ausgabe von Ihrem Regex zu füllen. Wenn ich diese automatisierten Informationen korrigiere-verwenden Sie die Tatsache, dass ich sie geändert habe, um Ihre Regex zu verbessern. Geben Sie mir so viel wie möglich die Möglichkeit, die Ausgabe Ihres Regex zu überprüfen und zu korrigieren: Niemand weiß besser, was ich zu kommunizieren wollte als ich.

Ich finde, wie diese, die ich finde, machen mein Leben am einfachsten. Besonders wenn ich E -Mail an ein Postsystem sende, über das Ihr Unternehmen praktisch kein funktionales internes Wissen verfügt.

Wenn Ihr Unternehmen interne Kenntnisse über bestimmte Postsysteme hat, verwenden Sie meine Auswahl aus Punkt 3, um zu informieren, welche Ansicht Sie mir anzeigen. Viele Leute wissen, was das US -Postsystem bei Verpackungen erwartet. Wenn ich uns in Punkt 3 auswähle, können Sie die Ansicht für eine US -Adresse angemessen aussehen. Wenn ich ein Land auswähle, über das Ihre Firma nichts weiß-eine generische drei Zeilen und lass mich den Rest machen; zwinge mich nicht, ASCII zu benutzen.

Und lassen Sie uns hier real sein-eine vollständige, enzyklopädische Datenbank aller globalen Postsysteme (öffentlich und privat) ist bestenfalls eine herkulische Aufgabe, wenn nicht sogar unmöglich. Es gibt beispielsweise Postsysteme, in denen nur der lokale Last-Mile-Flugzeug wirklich weiß, wo sich eine Adresse befindet. Manchmal ist es äußerst nützlich, Notizen an diesen Träger auf der Verpackung weiterzugeben. Die Abbildung des lokalen Wissens über jeden Rand -Fallträger in Ihre Datenbank ist in der Tat eine unmögliche Aufgabe.

Fragen Sie einfach Gödel. (Und fragen Sie sich dann, ob Sie versuchen, ein axiomatisches System zu verwenden, um ein Universum des Diskurses zu modellieren, geben oder nehmen eine Art Arithmetik wie festgelegte Theorie oder relationale Algebra.)

Answer 6

Kommentar der Antwort von Ben Alabaster: Um Adressen basierend auf dem Land zu formatieren, können Sie eine Formatierungstabelle verwenden, die die Bestellung der Spalten für jedes Land als separate Zeilen aufweist.

• AdressFormat (CountryCode, Feldname, Feldordnung)

Die Feldreihenfolge kann auch so codiert werden, dass sie komplexe Gitterlayouts verwenden.

Es macht keinen Sinn, Adressen nach Land zu trennen. Dies wird chaotisch, wenn die Anzahl der Länder zunimmt und Sie in Schwierigkeiten landen, wenn Sie alle Adressen eines internationalen Kunden finden möchten. Ein von Ben vorgeschlagener Adresstyp könnte auch zu Unklarheiten führen, wenn Sie eine Adresse haben, die sowohl eine Bauzahl als auch eine Apartmentnummer hat. Ich könnte in einem Apartmentkomplex sein, in dem jedes Gebäude einen anderen Namen hat. Dies ist in Indien sehr häufig.

Answer 7

ich benutze https://github.com/commerceguys/addressing Bibliothek zur Formatung internationaler Adressen und sie verwenden diese Elemente:

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

Dies hilft nicht, wenn Sie die Straße analysieren möchten (Name, Hausnummer, ...).

Übrigens. Wenn Sie nach einer Multilanguage Country -Liste suchen: https://github.com/umpirsky/country-list

Answer 8

Der einzige Weg besteht darin, sie zu teilen:

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

Da fast jedes Land seinen eigenen Standard für Adressierungsdaten hat und das Landland ein anderes Format an Zipcodes hat.
Sie können eine kleine Stichprobe von Problemen haben mein Post Aus einer ähnlichen Frage.

Dies sollte nicht sinnvoll sein, Adressen für jedes Land zu trennen, da es Länder gibt, in denen Sie nur wenige Anweisungen haben. Einige beliebte Konventionen umfassen keine Straßen in kleinen Dörfern, nur Dorfname und Anzahl, während Straßen in größeren Städten Adressen enthalten. Ich habe gelernt, dass es in Ungarns Hauptstadt - Budapest, es nur wenige Straßen mit demselben Namen gibt (Sie unterscheiden sie von der Bezirksnummer der Stadt), während andere Städte keine solchen Adressen haben (jemand aus Ungarn kann tatsächlich bestätigen, ob dies wahr ist). Die Gesamtzahl der Adressformate lautet also numer_of_countries multipliziert mit der Anzahl der Adressformate in diesem Land… kann mit verschiedenen Tabellen erfolgen, aber es wird schreckliche Arbeit sein.

Answer 9

Ich weiß, dass dies ein extrem altes Thema ist, das bereits beantwortet wurde, aber ich dachte, ich würde auch meine zwei Cent hineinwerfen. Es hängt alles davon ab, was Ihre Projektziele und wie Sie von Ihren Zielnutzern erwarten, dass sie Adressen eingeben. Bens Vorschlag ermöglicht es Ihnen, Adressen genau zu analysieren, aber andererseits könnte es zu einem längeren (und möglicherweise frustrierenden) Benutzerdateneingabeprozess führen. Der Vorschlag von Stephen Wrighton ist einfacher und kann für Benutzer einfacher sein, Adressen einzugeben.

Ich habe auch einige Modelle gesehen, in denen einfach eine "Adresse" -Säule verfügte, die eine typische Straßennummer, einen Typ, einen Straßennamen, eine Einheit / die Wohnung usw. erfasst. Innerhalb anderer Spalten. Ähnlich wie das Modell von Stephens Modell, außer Address1, Adresse2 und Adresse3, werden alle in einer Spalte konsolidiert.

Ich bin der Meinung, dass die flexibelsten Modelle in Abhängigkeit von Ihrer Interpretation von flexibles tendenziell diejenigen sind, die am wenigsten restriktiv sind.