Kleine Territorien und Sondercodes sind die Stelle, an der ein Länderdatenmodell erfährt, wie viel seiner Konstruktion eine Annahme war. Der Datensatz funktioniert wunderbar für die großen, eindeutigen, gut dokumentierten Orte, und dann kommt ein abhängiges Gebiet, ein Überseedepartement oder ein reservierter Code, und irgendetwas muss weichen.
Der Wert dieser Fälle liegt darin, dass sie billig hinzuzufügen sind und ungewöhnlich gut strukturelle Probleme offenlegen. Ein Modell, das sie bewältigt, hat üblicherweise mehrere wichtige Entscheidungen ausdrücklich gemacht.
Warum bricht die Annahme eines zweibuchstabigen Codes?
Weil die Codesysteme für Zwecke entworfen wurden, die nicht alle für jeden Ort einen zweibuchstabigen Code erfordern. Das zweibuchstabige System ist das vertraute, daneben gibt es ein dreibuchstabiges und ein numerisches System, und jedes löst ein anderes Problem. Das numerische System entstand insbesondere, um die Mehrdeutigkeit von Buchstaben über Sprachen hinweg zu vermeiden.
Die Codierung von Unterteilungen legt eine weitere Ebene darüber. Manche Orte erscheinen nur als Unterteilung innerhalb einer größeren Einheit und nicht als eigenständige Einheiten, und manche erscheinen in einem System, aber nicht in einem anderen. Ein Modell, das den zweibuchstabigen Code als Primärschlüssel der Welt behandelt, hat für solche Orte schlicht keinen Platz.
Die praktische Folge ist, dass der Primärschlüssel etwas sein sollte, das Ihr System kontrolliert, und nicht ein Wert, der aus einer Norm entlehnt ist, die eigene Umfangsentscheidungen trifft. Der Normcode wird dann zu einem Merkmal: wichtig, durchsuchbar, aber ersetzbar, wenn die Lage es verlangt.
Was soll mit reservierten und zurückgezogenen Codes geschehen?
Codes werden ergänzt, für künftige Nutzung reserviert und zurückgezogen. Zurückgezogene Codes verschwinden nicht aus der Welt; sie bleiben in historischen Aufzeichnungen, in archivierten Dokumenten und in alten Datenbanken, und sie werden in Importen noch lange auftauchen, nachdem der Code stillgelegt wurde.
Ein System muss entscheiden, was es mit ihnen tut. Sie rundheraus abzulehnen zerstört die Fähigkeit, Geschichte zu lesen. Sie stillschweigend als aktuell anzunehmen, erfindet eine Tatsache über die Gegenwart. Der gangbare Mittelweg besteht darin, sie mit einer Markierung anzunehmen, die besagt, dass sie nicht aktuell sind, und diese Unterscheidung überall sichtbar zu halten, wo der Wert angezeigt wird.
Dieselbe Logik gilt für Codes, die reserviert wurden, bevor sie je benutzt wurden. Ein reservierter Code ist kein Fehler, sondern eine Lücke in der Nummerierung, die jemand bewusst gewählt hat; eine Prüfregel, die ihn als fehlerhaft ablehnt, irrt über die Norm und nicht über die Eingabe.
Frühere Namen und die Namen, die ein Ort für sich selbst verwendet
Namen ändern sich, und die Änderung geschieht selten überall gleichzeitig. Eine Zeit lang ist ein neuer Name offiziell, während der alte noch in den meisten Dokumenten steht, und bei Ortsnamen unterscheiden sich die lokale und die internationale Form häufig.
Drei Arten von Namen sind daher zu unterscheiden. Der derzeitige offizielle Name, der Name in älteren Aufzeichnungen und der Name, den die dort lebenden Menschen lokal verwenden. Ein System, das nur einen der drei führt, liegt in die eine oder andere Richtung falsch, und welche Richtung es ist, hängt davon ab, wer liest.
Hier kann eine Datenbereinigung die Daten zerstören. Ein wohlgemeinter Normalisierungslauf, der jede historische Aufzeichnung auf den aktuellen Namen umschreibt, bringt das Archiv mit der Gegenwart in Übereinstimmung und bringt es mit sich selbst aus dem Einklang.
Nicht anwendbar ist nicht dasselbe wie unbekannt
Kleine Territorien machen diese Unterscheidung unmöglich zu übergehen, denn sie sind die Fälle, in denen ein Feld tatsächlich nicht gilt.
Ein Feld, das nicht gilt, bedeutet, dass das Konzept für diesen Ort nicht existiert; es gibt also nichts nachzuschlagen und keinen korrekten Wert. Ein Feld, das unbekannt ist, bedeutet, dass der Wert existiert und noch nicht festgestellt wurde. Beide erzeugen dieselbe leere Zelle und verlangen entgegengesetzte Reaktionen, und eine Checkliste, die sie als einen Zustand führt, erzeugt immer weiter Arbeit, die nicht abschließbar ist.
Ist das Feld ein Postleitzahlensystem, ist der Unterschied krass. Der Leitfaden zu den Postleitzahlenformaten nach Land behandelt, wie stark dieses Feld zwischen Orten variiert. Die Lage jedes Landes muss eingestuft werden, bevor irgendeine Prüfung sie berührt, denn ein System, das ein solches Feld als vorhanden annimmt, markiert jeden Eintrag ohne eines als unvollständig, und ein System, das annimmt, es könne fehlen, akzeptiert echte Fehleingaben.
Nicht unterstützt ist nicht dasselbe wie fehlerhaft
Das ist die Unterscheidung, die am häufigsten verloren geht, und die mit den klarsten sichtbaren Kosten für Nutzer.
Ein Wert, den ein System nicht unterstützt, ist kein falscher Wert. Er kann für seinen eigenen Ort vollkommen wohlgeformt sein, in einem Format, das das System einfach nie zu behandeln gelernt hat. Ihn der Nutzerin als ungültig zu melden, sagt ihr, sie habe einen Fehler gemacht, während die Einschränkung in Wahrheit auf der empfangenden Seite liegt.
| Was das System gefunden hat | Was es weiß | Was es sagen sollte |
|---|---|---|
| Einen Wert nach den Regeln, die es umsetzt | Der Wert ist gültig | Annehmen |
| Einen Wert nach Regeln, die es nicht umsetzt | Der Wert kann durchaus gültig sein | Hier nicht prüfbar |
| Einen Wert, der umgesetzte Regeln verletzt | Der Wert ist ungültig | Das konkrete Problem melden |
| Ein Feld, das es für diesen Ort nicht gibt | Es gibt nichts zu prüfen | Nicht anwendbar, nicht fehlend |
Die beiden mittleren Zeilen zusammenzulegen ist der verbreitete Fehler. Er erzeugt ein Produkt, das genau dort selbstsicher falsch liegt, wo sein Wissen am dünnsten ist, und Kundinnen aus diesen Orten merken es zuerst.
Für Entwickler: den dritten Zustand darstellbar machen
Ein binäres Ergebnis aus gültig oder ungültig kann die Aussage hier nicht geprüft nicht ausdrücken, also braucht das Prüfergebnis einen dritten Wert, der ehrlich bis in die Oberfläche durchgereicht wird. Das ist eine Änderung an einem Typ und keine an einer Regel, weshalb sie unter Zeitdruck gern übersprungen und später bereut wird.
Testen Sie anschließend die Grenzfälle absichtlich. Nehmen Sie einen Ort auf, dessen Code nur in einem System vorkommt, einen stillgelegten Code, einen Ort ohne Postleitzahlensystem und einen Namen, der sich geändert hat. Diese vier Fälle sind klein, schnell und ungewöhnlich ergiebig, und sie gehören dauerhaft in die Suite, statt erst dann hinzugefügt zu werden, wenn ein Ticket eintrifft.
Das Länder- und Regionenverzeichnis ist ein guter Ort, um zu sehen, wie ein Land und seine Unterteilungen dargestellt werden, wenn sie als vollwertiger Eintrag behandelt werden und nicht als Ausnahme, und der Eintrag zu den Vereinigten Staaten zeigt, wie ein vollständig beschriebener Eintrag neben einem dünneren aussieht.
Die Territorien, Codes, Namen und Feldzustände in diesem Beitrag sind konstruierte Grenzfälle, die zusammengestellt wurden, um ein Entwurfsproblem zu veranschaulichen. Sie sind kein Datensatz, sie geben nicht die tatsächliche Einstufung eines realen Territoriums wieder, und nichts hier sollte als Tatsache über einen bestimmten Ort zitiert werden.
Nächste Schritte
Nehmen Sie die vier obigen Grenzfälle in Ihre Suite auf und beobachten Sie, welche davon eine falsche Antwort erzeugen statt einer unbehandelten. Der Leitfaden zum Auswählen von Ländern für Testdaten erklärt, wie solche Fälle bewusst in einem Standardset platziert werden, und der Leitfaden zu grenzüberschreitenden Adressszenarien behandelt, was geschieht, wenn ein solcher Ort als eines von mehreren Ländern in einer einzigen Transaktion erscheint.