it-swarm.com.de

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? Anscheinend können viele Kompromisse geschlossen und viele Vor- und Nachteile bewertet werden - das wurde doch immer wieder gemacht? Vielleicht hat jemand zumindest einige Lektionen geschrieben, die er irgendwo gelernt hat?

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

Im Moment 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 eines globalen Umstiegs vorzubereiten (z. B. Benennung von Feldern wie Region anstelle von Bundesland oder Postleitzahl anstelle von Postleitzahl). etc.

96
John

Für eine internationalere Verwendung ist ein Schema zu berücksichtigen, das von Drupal Address Field 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 nette Perlen für die Interpretation und Validierung von Adressen auf internationaler Ebene entdecken. Es gibt auch eine Reihe von Verwaltungsgebieten in Nizza (Provinz, Bundesstaat, Oblast usw.) mit ISO-Codes.

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

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.
  • Wo möglich, Land und Verwaltungsbereich als ISO-Code speichern.
  • Wenn Sie es nicht wissen, lassen Sie die Felder locker. Einige Länder verwenden Felder, die Sie für selbstverständlich halten, möglicherweise nicht, selbst grundlegende Dinge wie locality & thoroughfare.
31
Samm Cooper

Als "internationaler" Nutzer gibt es nichts Frustrierenderes als den Umgang mit einer Website, die sich nur an Adressen im US-Format orientiert. Es ist zunächst 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 Ländern steht die Hausnummer vor dem Straßennamen, in anderen kommt sie nach. Manche haben Staaten, manche Regionen, manche Grafschaften, manche Kombinationen davon. Hier in Großbritannien ist die Postleitzahl keine Postleitzahl, sondern eine Postleitzahl, die sowohl Buchstaben als auch Zahlen enthält.

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

21
Andrew Ferrier

Sie sollten auf jeden Fall in Betracht ziehen, die Hausnummer nicht als Zahl, sondern als Zeichenfeld zu speichern, da es sich um Sonderfälle wie "Halbzahlen" handelt oder um meine aktuelle Adresse, die so etwas wie "129A" ​​lautet - aber das A wird nicht als Wohnung betrachtet Nummer für Zustelldienste.

17
Paul Fisher

Wenn Sie umfassende Informationen zur Verwendung von Postanschriften in anderen Ländern benötigen, finden Sie hier einen sehr guten Referenzlink (Columbia University):

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

17
splattne

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 um vier Positionen handelte, mit Ausnahme von Oslo mit 18 oder mehr.

Ich bin mir sicher, dass seit dem Moment, in dem wir die geografisch korrekten Postleitzahlen für alle unsere nationalen Adressen verwendet haben, einige Leute sich darüber beschwert haben, dass ihre Post zu spät eingetroffen ist. Es stellte sich heraus, dass diese Leute in der Nähe einer Grenze zwischen den Postgebieten lebten und dass jemand, der wirklich im Postgebiet lebte, beispielsweise um 1600, seine Post in Wirklichkeit an das Postgebiet 1610 adressieren sollte, da es sich in Wirklichkeit um das benachbarte Postgebiet handelte das hat ihm tatsächlich gedient, so dass es ein paar Tage länger dauern würde, bis seine Post an seinem richtigen Postort ankommt, da das richtige Postamt unerwünschte Eingriffe vornehmen musste, um sie an den falschen Postort weiterzuleiten ...

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

10
Erwin Smout

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 Beispieldatenmodelle unter DatabaseAnswers , zum Beispiel). Viele der bereits vorhandenen Antworten sind unter Umständen fehlerhaft (überhaupt keine Auswahl für DB Answers).

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

Meiner Meinung nach ist es oft (was nicht bedeutet immer ) Sinnvoll ist es, sowohl das 'Adressetikettenbild' der Adresse aufzunehmen als auch den Inhalt separat zu analysieren. Auf diese Weise können Sie Unterschiede zwischen der Platzierung von Postleitzahlen, z. B. zwischen verschiedenen Ländern, beheben. Sicher, Sie können einen Analysator und einen Formatierer schreiben, die die Exzentrizitäten verschiedener Länder behandeln (z. B. haben US-Adressen 2 oder 3 Zeilen; im Gegensatz dazu können britische Adressen erheblich mehr enthalten; eine Adresse, an die ich in regelmäßigen Abständen schreibe, hat 9 Zeilen). Es kann jedoch einfacher sein, die Analyse und Formatierung vom Menschen durchführen zu lassen und das DBMS nur die Daten speichern zu lassen.

7

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 zu tun haben, die Einführung von Alphas in die Codes beschließt?

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

7
seanb

Ich habe festgestellt, dass es am einfachsten ist, alle möglichen Felder von der kleinsten diskreten Einheit bis zur größten aufzulisten. Die Benutzer füllen die Felder aus, die sie für richtig halten. Meine Adresstabelle sieht so aus:

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

Hinzu kommt, was @ Jonathan Leffler und @ Paul Fisher gesagt haben

Wenn Sie jemals damit rechnen, Postanschriften für Kanada oder Mexiko zu Ihren Anforderungen hinzuzufügen, speichern Sie postal-code als String ist ein Muss. Kanada hat alphanumerische Postleitzahlen und ich kann mich nicht erinnern, wie Mexiko aus der Vogelperspektive aussieht.

6
Ken Gentle

Wo ist der "Kompromiss" beim Speichern der Postleitzahl als NUMBER oder VARCHAR? Das ist nur eine Wahl - es ist kein Kompromiss, es sei denn, es gibt Vorteile für beide und Sie müssen einige Vorteile aufgeben, um andere zu erhalten.

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

2
Mark Brady

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

sie könnten eine länderspezifische Adressbehandlung mit zwei Tabellen durchführen: Eine generische Tabelle mit 10 VARCHAR2-Spalten, 10 Nummernspalten, eine andere Tabelle, die diese Felder Eingabeaufforderungen zuordnet, und eine Länderspalte, die eine Adressstruktur mit einem Land verknüpft.

2
Shanmu

Wenn Sie jemals eine Adresse verifizieren oder zur Abwicklung 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 gebräuchliches optionales Feld für die Validierung von Zahlungskartentransaktionen ohne Verwendung der gesamten Adresse. Haben Sie also ein separates und großzügig bemessenes Feld dafür (mindestens 10 Zeichen).

1
Ted Bigham

Inspiriert von Datenbankantworten

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails
1
Jowen

Ich würde einfach alle Felder in einem großen NVARCHAR (1000) -Feld mit einem Textarea-Element zusammenfassen, 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 so ärgerlich, wenn Sie eine Adresse haben, die nicht gut zu diesem Format passt (und es gibt, wie Sie wissen, auch andere Länder als die USA).

0
erikkallen