Was ist eine universelle Methode zum Speichern einer geografischen Adresse / eines geografischen Standorts in einer Datenbank? [geschlossen]

Was ist das richtige Format einer geografischen Adresse / eines geografischen Standorts, das zu jeder Adresse auf der Erde passt? Im Moment habe ich:

• Land
• Stadt
• Straße
• Nummer
• Textdaten (der Einfachheit halber)
• Postleitzahl
• lat / lng

Aber ich glaube, ich kann es verbessern: Es könnte einen Staat / eine Region eines Landes oder eine ähnliche Region geben. Oder kein Gebiet / Region / Bundesstaat, zum Beispiel in Singapur oder Hongkong.

Möglicherweise gibt es keine Straße, sondern eine Straße oder einen Boulevard oder etwas anderes. Eine Nummer eines Gebäudes könnte zusammengesetzt sein. Es könnte einen Boden geben. Eine Zimmernummer. Etc....

Google hat eine Bibliothek entwickelt , mit deren Hilfe Postanschriften für jedes Land der Welt validiert werden können. Mit dieser Bibliothek können Sie ein Schema zum Speichern dieser Daten entwerfen.

Suchen Sie zunächst nach den am häufigsten benötigten Feldern in den Adressen Ihres Zielkundenstamms. Wenn Sie weitere Länder mit unterschiedlichen Anforderungen identifizieren, können Sie Ihr Schema weiter anpassen.

Die universelle Möglichkeit, eine geografische Adresse / einen geografischen Standort in einer Datenbank zu speichern, ist die folgende:

[Address] nvarchar(max) not null

Dies erfordert die geringste Menge an Programmcode (und reduziert so die Wartungskosten) und ist mit jeder Adresse voll kompatibel. Es hat jedoch drei große Probleme:

• Das Fehlen einer Datenvalidierung bedeutet, dass das Feld für andere Zwecke als zum Speichern der Adresse verwendet werden kann. Einer der Zwecke ist ein DOS-Angriff, der den Speicherplatz Ihrer Datenbank ausfüllt, indem 2 GB Daten in das Adressfeld eingegeben werden.

• Die auf diese Weise gespeicherten Daten können nicht für Business Intelligence- und Data Mining-Zwecke verarbeitet werden. Wie viele Benutzer kommen beispielsweise aus Indien? Es ist nicht einfach zu sagen, da diese Adressen nicht normalisiert werden.

• Die Benutzer können versehentlich eine unvollständige oder eindeutig falsche Adresse eingeben.

Begrenzen Sie das Feld auf ein Ihrer Meinung nach angemessenes Limit, um das erste Problem zu beheben. Persönlich würde ich mit 1000 Zeichen beginnen und es dann basierend auf der Länge der Adressen reduzieren, die von den ersten Benutzern eingegeben wurden, sobald Sie einen Datensatz erhalten, der groß genug ist.

Um die beiden anderen Probleme zu beheben, können Sie eine Drittanbieter-API verwenden, die Adressen analysiert und Ihnen die Daten anzeigt, die Land, Stadt, Postleitzahl usw. enthalten. Wenn möglich, sollte die API in der Lage sein, die Adresse anzuzeigen Eine Karte an den Benutzer zurück, um das Risiko zu verringern, dass der Benutzer eine unvollständige oder falsche Adresse eingibt: Die meisten Benutzer wissen, wo sie leben, und wenn sie eine andere Position auf einer Karte sehen, erhalten sie sofort einen Hinweis, dass sie ihre Eingaben überprüfen sollten.

Beachten Sie, dass die von Ihnen verwendete API nicht perfekt ist. Es werden die meisten Adressen gefunden, aber nicht alle. Dies bedeutet , dass , wenn die API sagt , dass die Adresse nicht existiert, aber der Benutzer besteht darauf , dass dies der Fall, sollten Sie von vornherein das Vertrauen der Benutzer, selbst wenn er könnte falsch sein.

Dies bedeutet auch, dass Sie die Eingaben des ursprünglichen Benutzers neben dem Ergebnis der API speichern sollten. Dies bedeutet, dass das Schema wie folgt lautet:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

Es gibt keinen.

Jedes Land hat unterschiedliche Adressformate. Wenn Sie Glück haben, und sie haben überhaupt ein Format!

Offensichtlich geben Ihnen Breiten- und Längengrade einen Punkt auf dem Globus, aber es ist nicht wirklich nützlich, um einzelne Häuser zu identifizieren. Betrachten Sie zum Beispiel einen Hochhaus.

Am besten überprüfen Sie die Post in jedem Land auf ein offizielles Format. Dies kann sehr hilfreich für Ihre Backend-Datenbank sein. Sie müssen es jedoch wahrscheinlich für Endbenutzer vereinfachen, da es viel mehr Felder enthält, als die meisten Benutzer gewohnt sind.

In Großbritannien gibt es zum Beispiel Dinge wie "doppelt abhängiger Ort", aber niemand würde wissen, was das bedeutet, wenn Sie ihn fragen.

Das einzige universelle Format ist ein einzelnes Textfeld, das mehrere Textzeilen enthalten kann. Dies ermöglicht jede mögliche Adresse auf der Erde.

Ich habe Softwarelösungen entwickelt, die in vielen Ländern eingesetzt werden. Wir gehen dieses Problem an, indem wir zuerst mit der größeren Entität beginnen, dh, das Land verfügt dann über Felder, die am wenigsten verbreitet oder am kleinsten sind. Es funktioniert gut für alle Länder, mit denen wir bisher experimentiert haben. Wir haben auch ein intelligentes System zur Verhinderung von Duplikaten und eine Fusion für diejenigen, die irgendwie in das System eingedrungen sind, da die Benutzer sehr "kreativ" sind. Im Admin-Bereich haben wir eine Adressfeldreihenfolge pro Ländereinstellung. Das heißt, Japan hat zuerst die Postleitzahl, wohin als letztes Großbritannien / USA.

Im Allgemeinen verwenden wir:

• Land
• Postleitzahl
• Bundesstaat / Provinz / Präfektur / Landkreis
• Großstadt Stadt Dorf
• Straße / Straße / Block
• Name / Nummer des Gebäudes
• Spezifische / benutzerdefinierte Informationen

Einmal eingegeben und gespeichert, kann eine konjugierte Version angezeigt werden, ohne dass Felder erforderlich sind.

Wie gesagt, dies funktioniert in allen Ländern, in denen wir Software haben, und ist das Ergebnis der Entwicklung seit 1989.

Hoffe das hilft irgendwie oder liefert zumindest einen anderen Einblick.

Wie bereits erwähnt, ist das universellste (aber unpraktisch zu validierende und vielleicht am wenigsten nützliche) Feld ein einziges großes Unicode-Feld.

Sie können das Land von der restlichen Adresse trennen und als ISO-Ländercode speichern. Dies würde das Land normalisieren und eine nützliche Funktion bei der Validierung des Restes der Adresse bieten.

Sie können auch die Postleitzahl (PLZ) von der übrigen Adresse trennen. Dies hätte auch eine gewisse Nützlichkeit bei der Validierung des Restes der Adresse und könnte hilfreich (wenn auch ungenau) bei der Geolokalisierung sein. Zum Beispiel: In Kanada können Sie jede Adresse eindeutig identifizieren, indem Sie nur Postleitzahl und Hausnummer angeben. Dies ist möglicherweise nicht in allen Ländern der Fall.

Die Zuordnung von Feldern zu Bundesstaaten / Provinzen oder Städten wird aufgrund der unterschiedlichen Formulierungen der Adressen in den einzelnen Ländern zunehmend problematischer. Ich habe Adresstabellen mit solchen Feldern eingerichtet, weil das anfängliche Publikum sich auf Nordamerika konzentriert und weiß, dass ein internationales Publikum ein Problem darstellen würde umständliche und möglicherweise fehleranfällige Kompromisse - definitiv nicht universell.

Entgegen der Antwort von Mitchdav würde ich davon abraten, die Bibliothek von Google zu verwenden. Ich suchte im Repository nach verschiedenen internationalen Orten mit unorthodoxen Adressierungsschemata in der Hoffnung, Komponententestdaten zu finden, aber besorgniserregend fand ich im gesamten Repository keine Treffer.

Ich denke, Ihre beste Wahl ist es, eine Adresse als mehrzeiligen Freitext zu behandeln. Es ist schade, dass Sie möglicherweise nicht alle Adressen validieren können, aber einige Adressierungsformate sind wirklich seltsam und möglicherweise unerwartet, und letztendlich liegt die Verantwortung für das Ausfüllen der richtigen Adresse beim Benutzer und in den meisten Anwendungen trägt der Benutzer die negativen Folgen des Ausfüllens einer ungültige Adresse.

Vielleicht können Sie einen Validator verwenden, um eine Warnung zu übermitteln , aber mehr nicht. Aber lehnen Sie nicht Adressen ab, die nicht gültig sind, da Sie sonst einige Kunden verlieren könnten. Was zu der Frage führt, wie die Warnung an den Benutzer so kommuniziert werden soll, dass, wenn der Benutzer in einem Gebiet mit einem seltsamen Adressformat lebt, es sicher ist, die Warnung zu ignorieren ...

Wie Sie sagen, jede Adresse auf der Erde gibt es nur lat lang oder ...

https://what3words.com

Welche 3 Wörter, ist ein Algorithmus (also keine Datenbank, die in irgendetwas eingebettet werden kann), der ein 3x3 Meter großes Feld von irgendwo auf der Erde definieren kann.

Tonga und einige andere Staaten haben es als ihr Postleitzahlensystem übernommen, während es es als Overlay nicht ersetzen wird. Es ist ziemlich cool und sehr gut gebaut und durchdacht.