Best Practices zum Speichern von Postanschriften in einer Datenbank (RDBMS)?

Gibt es gute Referenzen für Best Practices zum Speichern von Postanschriften in einem RDBMS? Es scheint, dass es viele Kompromisse gibt und viele Vor- und Nachteile für jeden zu bewerten sind - sicherlich wurde dies immer wieder getan? Vielleicht hat jemand zumindest einige Lektionen geschrieben, die er irgendwo gelernt hat?

Beispiele für die Kompromisse, über die ich spreche, sind das Speichern der Postleitzahl als Ganzzahl gegenüber einem Zeichenfeld, sollte die Hausnummer als separates Feld oder Teil der Adresszeile 1 gespeichert werden, sollten Suite- / Apartment- / usw.-Nummern normalisiert oder nur als gespeichert werden Textblock in Adresszeile 2, wie gehen Sie mit zip +4 um (separate Felder oder ein großes Feld, Ganzzahl vs. Text)? etc.

An dieser Stelle beschäftige ich mich hauptsächlich mit US-Adressen, aber ich stelle mir vor, dass es einige bewährte Methoden gibt, um sich auf die Möglichkeit vorzubereiten, auch global zu werden (z. B. Felder wie Region anstelle von Bundesland oder Postleitzahl anstelle von Postleitzahl entsprechend zu benennen). etc.

Für eine internationalere Verwendung ist ein Schema zu berücksichtigen, das vom Drupal-Adressfeld verwendet wird . Es basiert auf dem xNAL-Standard und scheint die meisten internationalen Fälle abzudecken. Wenn Sie sich ein wenig mit diesem Modul befassen, werden Sie einige schöne Perlen für die internationale Interpretation und Validierung von Adressen entdecken. Es gibt auch eine Reihe von Verwaltungsbereichen (Provinz, Bundesland, Gebiet usw.) mit ISO-Codes.

Hier ist der Kern des Schemas, das von der Modulseite kopiert wurde:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

Eine Lektion, die ich gelernt habe:

• Speichern Sie nichts numerisch.
• Speichern Sie Land und Verwaltungsbereich nach Möglichkeit als ISO-Codes.
• Wenn Sie es nicht wissen, müssen Sie nachlässig Felder anfordern. Einige Länder verwenden möglicherweise keine Felder, die Sie für selbstverständlich halten, selbst grundlegende Dinge wie locality& thoroughfare.

Als "internationaler" Benutzer gibt es nichts Frustrierenderes als den Umgang mit einer Website, die sich nur an Adressen im US-Format orientiert. Es ist anfangs etwas unhöflich, wird aber zu einem ernsthaften Problem, wenn die Validierung auch zu eifrig ist.

Wenn Sie daran interessiert sind, global zu agieren, ist der einzige Rat, den ich habe, die Dinge frei zu halten. Verschiedene Länder haben unterschiedliche Konventionen - in einigen steht die Hausnummer vor dem Straßennamen, in einigen nach. Einige haben Staaten, einige Regionen, einige Landkreise, einige Kombinationen davon. Hier in Großbritannien ist die Postleitzahl keine Postleitzahl, sondern eine Postleitzahl, die sowohl Buchstaben als auch Zahlen enthält.

Ich würde einfach empfehlen, ~ 10 Zeilen Zeichenfolgen variabler Länge zusammen mit einem separaten Feld für eine Postleitzahl (und seien Sie vorsichtig, wie Sie dies beschreiben, um mit den nationalen Empfindlichkeiten umzugehen). Lassen Sie den Benutzer / Kunden entscheiden, wie er seine Adressen schreibt.

Wenn Sie umfassende Informationen darüber benötigen, wie andere Länder Postanschriften verwenden, finden Sie hier einen sehr guten Referenzlink (Columbia University):

Franks zwanghafter Leitfaden für Postanschriften
Effektive Adressierung für internationale Post

Aufgrund von Sonderfällen wie "Halbzahlen" oder meiner aktuellen Adresse, die so etwas wie "129A" ​​ist, sollten Sie die Hausnummer auf jeden Fall als Zeichenfeld und nicht als Zahl speichern. Das A wird jedoch nicht als Wohnung betrachtet Nummer für Lieferservices.

Ich habe dies getan (Adressstrukturen in einer Datenbank rigoros modellieren) und würde es nie wieder tun. Sie können sich nicht vorstellen, wie verrückt die Ausnahmen sind, die Sie in der Regel berücksichtigen müssen.

Ich erinnere mich vage an ein Problem mit norwegischen Postleitzahlen (glaube ich), bei denen es sich alle um vier Positionen handelte, mit Ausnahme von Oslo mit 18 oder so.

Ich bin mir sicher, dass sich von dem Moment an, als wir die geografisch korrekten Postleitzahlen für alle unsere eigenen nationalen Adressen verwendeten, einige Leute beschwerten, dass ihre Post zu spät ankam. Es stellte sich heraus, dass diese Menschen in der Nähe einer Grenze zwischen Postgebieten lebten, und trotz der Tatsache, dass jemand wirklich im Postgebiet lebte, beispielsweise 1600, sollte seine Post in Wirklichkeit an das Postgebiet 1610 gerichtet werden, da es in Wirklichkeit das benachbarte Postgebiet war das diente ihm tatsächlich, so dass das Senden seiner Post an seinen richtigen Postbereich einige Tage länger dauern würde, bis sie eintrifft, da im richtigen Postamt unerwünschte Eingriffe erforderlich waren, um sie an den falschen Postbereich weiterzuleiten ...

(Am Ende haben wir diese Personen mit einer Adresse im Ausland im Land mit dem ISO-Code 'ZZ' registriert.)

Sie sollten auf jeden Fall " Ist dies eine gute Möglichkeit, Adressinformationen in einer relationalen Datenbank zu modellieren " konsultieren , aber Ihre Frage ist kein direktes Duplikat davon.

Es gibt sicherlich viele bereits vorhandene Antworten (siehe beispielsweise die Beispieldatenmodelle bei DatabaseAnswers ). Viele der bereits vorhandenen Antworten sind unter bestimmten Umständen fehlerhaft (DB-Antworten werden überhaupt nicht ausgewählt).

Ein wichtiges Thema ist der Umfang der Adressen. Wenn Ihre Datenbank mit internationalen Adressen umgehen muss, müssen Sie flexibler sein als wenn Sie nur mit Adressen in einem Land umgehen müssen.

Meiner Ansicht nach ist es oft (was nicht immer bedeutet ) sinnvoll, sowohl das Adressetikettenbild der Adresse aufzuzeichnen als auch den Inhalt separat zu analysieren. Auf diese Weise können Sie Unterschiede zwischen der Platzierung von Postleitzahlen, beispielsweise zwischen verschiedenen Ländern, beseitigen. Natürlich können Sie einen Analysator und einen Formatierer schreiben, die die Exzentrizitäten verschiedener Länder verarbeiten (z. B. haben US-Adressen 2 oder 3 Zeilen; britische Adressen können dagegen erheblich mehr haben; eine Adresse, an die ich regelmäßig schreibe, hat 9 Zeilen). Es kann jedoch einfacher sein, die Menschen die Analyse und Formatierung durchführen zu lassen und das DBMS nur die Daten speichern zu lassen.

Wenn Sie nicht mit den Straßennummern oder Postleitzahlen rechnen, laden Sie nur zu zukünftigen Schmerzen ein, indem Sie sie als Zahlen speichern.

Sie könnten hier und da ein paar Bytes sparen und vielleicht einen schnelleren Index erhalten, aber was tun Sie, wenn die US-Post oder ein anderes Land, mit dem Sie es zu tun haben, über die Einführung von Alphas in die Codes entscheidet?

Die Kosten für Speicherplatz werden viel billiger sein als die Kosten für die spätere Behebung ... y2k jemand?

Hinzufügen zu dem, was @ Jonathan Leffler und @ Paul Fisher gesagt haben

Wenn Sie jemals damit rechnen, Postanschriften für Kanada oder Mexiko zu Ihren Anforderungen hinzuzufügen, ist das Speichern postal-codeals Zeichenfolge ein Muss. Kanada hat alphanumerische Postleitzahlen und ich kann mich nicht erinnern, wie Mexiko auf den ersten Blick aussieht.

Ich habe festgestellt, dass das Auflisten aller möglichen Felder von der kleinsten diskreten Einheit bis zur größten der einfachste Weg ist. Benutzer füllen die Felder aus, die sie für richtig halten. Meine Adresstabelle sieht folgendermaßen aus:

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

Wo ist der "Kompromiss" bei der Speicherung der Postleitzahl als NUMMER oder VARCHAR? Das ist nur eine Wahl - es ist kein Kompromiss, es sei denn, beide haben Vorteile und Sie müssen einige Vorteile aufgeben, um andere zu erhalten.

Sofern die Summe der Reißverschlüsse überhaupt keine Bedeutung hat, ist Reißverschlüsse als Zahl nicht sinnvoll.

Dies mag ein Overkill sein, aber wenn Sie eine Lösung benötigen, die mit mehreren Ländern funktioniert, und Teile der Adresse programmgesteuert verarbeiten müssen:

Sie können eine länderspezifische Adressbehandlung mit zwei Tabellen durchführen: Eine generische Tabelle mit 10 VARCHAR2-Spalten, 10 Zahlenspalten, eine weitere Tabelle, die diese Felder Eingabeaufforderungen zuordnet und eine Länderspalte enthält, die eine Adressstruktur mit einem Land verknüpft.

Wenn Sie jemals eine Adresse überprüfen oder zur Verarbeitung von Kreditkartenzahlungen verwenden müssen, benötigen Sie zumindest eine kleine Struktur. Ein Freiform-Textblock funktioniert dafür nicht sehr gut.

Die Postleitzahl ist ein allgemeines optionales Feld zum Validieren von Zahlungskartentransaktionen ohne Verwendung der gesamten Adresse. Haben Sie also ein separates und großzügiges Feld dafür (mindestens 10 Zeichen).

Inspiriert von Database Answers

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Ich würde einfach alle Felder in einem großen NVARCHAR (1000) -Feld zusammenfügen, mit einem Textbereichselement, für das der Benutzer den Wert eingeben kann (es sei denn, Sie möchten eine Analyse für z. B. Postleitzahlen durchführen). Alle diese Eingaben für Adresszeile 1, Adresszeile 2 usw. sind nur dann so ärgerlich, wenn Sie eine Adresse haben, die nicht gut zu diesem Format passt (und Sie wissen, dass es andere Länder als die USA gibt).