Ist es eine gute Idee, eine ganze Spalte zum Speichern von US Postleitzahlen in einer Datenbank zu benutzen?

StackOverflow https://stackoverflow.com/questions/893454

Frage

Von dem ersten Blick scheint es, ich habe zwei grundlegende Optionen für die Speicherung von Postleitzahlen in einem Datenbank-Tabelle:

  1. Text (wahrscheinlich am häufigsten), das heißt char(5) oder varchar(9) unterstützen +4 Erweiterung
  2. Numeric, d.h. 32-Bit-Ganzzahl

Beide würden die Anforderungen der Daten erfüllen, wenn wir, dass es davon ausgehen, sind keine internationalen Bedenken. In der Vergangenheit haben wir in der Regel nur den Text Weg gegangen, aber ich habe mich gefragt, ob jemand das Gegenteil tut? Nur von kurzem Vergleich sieht es aus wie die ganze Zahl Methode zwei klare Vorteile:

  • Es ist durch seine Natur, automatisch auf Numerik nur begrenzt (während ohne Validierung könnte der Textstil speichern Buchstaben und solche, die meines Wissens nicht, sind, je in einem ZIP-Code gültig). Diese nicht bedeuten, wir könnten / würden / verzichten sollten Benutzereingabe als normale Validierung, aber!
  • Es braucht weniger Platz, 4 Bytes sein (was auch für 9-stellige Postleitzahlen viel sein soll) anstelle von 5 oder 9 Byte.

Auch scheint es, wie es ist nicht die Display-Ausgabe viel schaden würde. Es ist trivial, eine ToString() auf einen numerischen Wert zu schlagen, mit einfachen String-Manipulation einen Bindestrich oder Leerzeichen oder was auch immer für die vier Erweiterung einzufügen, und verwenden Sie String-Formatierung führenden Nullen wiederherzustellen.

Gibt es etwas, das für US-nur Postleitzahlen mit int als Datentyp entmutigen würde?

War es hilfreich?

Lösung

Ein numerischer Postleitzahl ist - in einem kleinen Weg - irreführend.

Zahlen sollten etwas bedeuten numerisch . Postleitzahlen addieren oder subtrahieren oder beteiligen sich an keine numerische Operationen. 12309 -. 12345 nicht die Entfernung von der Innenstadt Schenectady zu meiner Nachbarschaft berechnen

Zugegeben, für Postleitzahlen, niemand ist verwirrt. Doch für andere Zahlen wie Felder, kann es verwirrend sein.

Da Postleitzahlen nicht Zahlen sind - sie passieren nur mit einem eingeschränkten Alphabet kodiert werden - Ich schlage vor, ein numerisches Feld zu vermeiden. Die 1-Byte-Einsparung ist nicht viel wert. Und ich denke, dass Sinn ist wichtiger als das Byte.

Bearbeiten .

„Wie für führende Nullen ...“ ist mein Punkt. Zahlen haben keine führenden Nullen. Das Vorhandensein von sinnvollen führenden Nullen auf Postleitzahlen ist ein weiterer Beweis dafür, dass sie nicht numerisch sind.

Andere Tipps

Werden Sie jemals Postleitzahlen nicht in den USA speichern? Kanada ist 6 Zeichen mit einigen Buchstaben. Ich in der Regel nur 10 Zeichen Feld. Speicherplatz ist billig, Ihr Datenmodell zu überarbeiten, die nicht ist.

eine Zeichenkette mit Validierung verwenden. Zip-Codes können mit 0 beginnen, so numerisch kein geeigneter Typ ist. Auch dies gilt ordentlich auf internationale Postleitzahlen (z UK, die bis zu 8 Zeichen). Im unwahrscheinlichen Fall, dass Postleitzahlen ist ein Engpass, können Sie es auf 10 Zeichen begrenzen könnten, aber überprüfen Sie Ihr Zielformate zuerst.

sind hier Validierung Regexes für Großbritannien, USA und Kanada.

Ja, Sie können Pad zurück, um die führenden Nullen zu erhalten. Allerdings sind Sie werfen theoretisch weg Informationen, die im Falle von Fehlern helfen könnte. Wenn jemand 1235 in der Datenbank findet, ist, dass ursprünglich 01235, oder hat eine andere Ziffer verpasst?

Aus der Praxis sagt sollten Sie sagen, was Sie meinen. Eine Postleitzahl ist ein Code, keine Zahl. Gehst du href="https://stackoverflow.com/questions/290597/phone-number-columns-in-a-database"> addieren / subtrahieren / multiplizieren / dividieren Postleitzahlen

Normalerweise würde man einen nicht-numerischen Datentyp verwenden, wie zum Beispiel eines varchar, die für mehr Postleitzahl Typen erlauben würde. Wenn Sie tot Satz sind nur erlaubt 5-stellige [XXXXX] oder 9-stellige [XXXXX-XXXX] Postleitzahlen, könnte man dann eine char (5) oder char (10), aber ich würde es nicht empfehlen. Varchar ist die sicherste und vernünftige Wahl.

Edit: Es sollte auch beachtet werden, dass, wenn Sie auf dem Tun numerische Berechnungen auf dem Feld nicht planen, sollen Sie nicht einen numerischen Datentyp verwenden. Postleitzahl ist keine Zahl in dem Sinne, dass man gegen sie addieren oder subtrahieren. Es ist nur eine Zeichenfolge, die typischerweise aus Zahlen werden aus geschieht, so sollten Sie verzichten numerische Datentypen für ihn verwenden.

Aus technischer Sicht, einige Punkte hier aufgeworfenen sind ziemlich trivial. Ich arbeite mit Adressdatenbereinigung auf eine täglich Basis - insbesondere Reinigung Adressdaten aus der ganzen Welt. Es ist keine triviale Aufgabe, von einer Strecke der Phantasie. Wenn es darum geht Codes zip, Sie könnte speichert sie als eine ganze Zahl, obwohl es nicht „semantisch“ korrekt. Tatsache ist, dass die Daten einer numerischen Form ist, ob oder nicht, streng genommen ist es ist als numerischer Wert.

Allerdings ist der sehr reale Nachteil, sich als numerische Typen von Speichern ist, dass Sie die Fähigkeit, leicht zu sehen verlieren werden, wenn die Daten falsch eingegeben wurden oder wenn das System entfernt führende Nullen was teure Operationen (dh fehlende Werte) zu validieren möglicherweise ungültige Postleitzahlen, die sonst korrekt waren.

Es ist auch sehr schwer, den Benutzer zur Eingabe von korrekten Daten zu erzwingen, wenn eine der Auswirkungen eine Verzögerung von Geschäft. Benutzer haben oft nicht die Geduld korrekte Daten einzugeben, wenn es nicht sofort offensichtlich ist. eine regex ein Weg ist, korrekte Daten zu gewährleisten, aber wenn der Benutzer einen Wert eingibt, der nicht entspricht und sie einen Fehler angezeigt, können sie zusammen mit diesem Wert weglassen gerade oder etwas eingeben, entspricht aber ansonsten falsch. Ein Beispiel [mit kanadischen Postleitzahlen] ist, dass man oft A0A 0A0 eingetragen, die nicht gültig ist, sondern entsprechen den regulären Ausdruck für kanadische Postleitzahlen. Mehr als oft nicht, wird dies von den Nutzern eingegeben, die eine Postleitzahl zu schaffen gezwungen sind, aber sie wissen entweder nicht, was es ist, oder haben nicht alle es richtig.

Ein Vorschlag ist, die gesamte Eintragung als Einheit zu validieren Validieren, dass die Postleitzahl korrekt ist, wenn sie mit dem Rest der Adresse verglichen. Wenn es falsch ist, dann bietet alternative gültige Postleitzahlen für die Adresse wird es für sie zur Eingabe von gültigen Daten zu erleichtern. Ebenso, wenn die Postleitzahl korrekt für die Adresse, aber die Hausnummer liegt außerhalb der Domäne dieser Postleitzahl, dann bietet alternative Hausnummern für die PLZ / Straßen Kombination.

Wenn Sie eine geschäftliche Anforderung haben mathematische Berechnungen auf PLZ-Daten auszuführen, gibt es keinen Punkt in einen INT verwenden. Sie sind über Engineering.

Hope, das hilft,

Bill

Nein, da

  • Sie nie tun mathematische Funktionen auf PLZ
  • Könnte enthalten Striche
  • Könnte mit 0
    • starten
  • manchmal NULL-Wert als Null bei skalaren Typen interpretiert wie ganze Zahl (zum Beispiel, wenn Sie die Daten exportieren irgendwie)
  • Postleitzahl, auch wenn es eine Zahl ist, eine Bezeichnung eines Bereichs ist, dies bedeutet, ist ein Name anstelle einer numerischen Menge von etwas

Postleitzahl ist wirklich ein codiertes Namespace, wenn man darüber nachdenkt. Traditionell Ziffern, sondern auch ein Bindestrich und Großbuchstaben:

"10022-SHOE"

http://www.saksfifthavenue.com/main/10022-shoe.jsp

Realistisch betrachtet, wird eine Menge von Business-Anwendungen nicht benötigt diese Kante Fall zu unterstützen, auch wenn es gültig ist.

Integer ist schön, aber es funktioniert nur in den USA, weshalb die meisten Menschen es nicht tun. Normalerweise benutze ich nur eine varchar (20) oder so. Wahrscheinlich viel des Guten für jede locale.

Wenn Sie eine ganze Zahl für die US-Zips verwenden, würden Sie die Hauptrolle von 10.000 multipliziert werden sollen, und die 4 hinzuzufügen. Die Codierung in der Datenbank hat nichts mit der Eingabevalidierung zu tun. Sie können jederzeit die Eingabe erfordern gültig oder nicht zu sein, aber die Lagerung ist darauf an, wie viel denken Sie, Ihre Anforderungen oder die USPS ändern wird. (Hinweis: Ihre Anforderungen wird ändern.)

ich vor kurzem gelernt , dass in Ruby ein Grund, warum Sie wollen würde dies zu vermeiden, weil es einige Postleitzahlen, die mit führenden Nullen beginnen, die-wenn, wie in gespeicherten Integer automatisch auf oktal umgewandelt werden.

die docs :

  

Sie können ein spezielles Präfix verwenden Zahlen in dezimal zu schreiben, hexadezimal, oktal oder Binärformaten. Für Dezimalzahlen verwenden, um einen Präfix von 0T, für Hexadezimalzahlen das Präfix 0x verwenden, für Oktalzahlen einen Präfix von 0 oder 0o verwenden ...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top