Länder- und Währungscodes in Daten: ISO 3166-1 und ISO 4217 ohne Überraschungen

Worum es geht

ISO 3166-1 gibt jedem Land oder Gebiet einen zweibuchstabigen Code (CH), einen dreibuchstabigen Code (CHE) und eine dreistellige Nummer (756). Die UN-M49-Liste (zitiert) veröffentlicht numerische Gebietscodes neben den ISO-Alpha-3-Codes, und BCP 47 (RFC 5646, zitiert) verwendet Alpha-2-Codes und M49-Ziffern als Region-Subtags. RFC 5646 hält zudem zwei Fallen fest: ISO 3166-1 hat „ausnahmsweise reservierte" Codes, von denen UK nur ein Synonym für das vergebene GB ist, und AA, QM bis QZ, XA bis XZ sowie ZZ sind für private Nutzung reserviert. ISO 4217 gibt Währungen einen dreibuchstabigen Code, einen numerischen Code und einen Exponenten für die Nebeneinheit. Die aktuelle Liste wird von der Pflegestelle SIX (zitiert) als XML veröffentlicht: CHF und EUR haben 2 Nebeneinheiten, JPY 0, BHD 3, CLF 4; Edelmetalle, der Testcode XTS sowie XXX („keine Währung") haben keine; und die Datei trägt ein Veröffentlichungsdatum, weil sich Einträge ändern.

Warum es wichtig ist

Codes wirken stabil und selbsterklärend, weshalb sie hart codiert werden. Doch Währungen werden umbenannt und ersetzt, Gebiete ändern ihren Status, und Code, der zwei Nachkommastellen annimmt, rundet Yen- und Dinar-Beträge falsch. Ein Ländercode sagt zudem nichts Zuverlässiges über die Sprache, Zeitzone oder Währung einer Person oder eines Kontos aus; das sind eigenständige Attribute.

So wird es angewendet

• Den Alpha-2-Ländercode und den Alpha-3-Währungscode als Grossbuchstaben-Text mit einem Check Constraint oder einem Fremdschlüssel auf eine Codetabelle speichern; keine Anzeigenamen speichern, sondern sie am Rand übersetzen.
• Die Codetabellen als Daten mit den Spalten valid_from und valid_to sowie einer Quellversion führen und die Liste der Pflegestelle regelmässig neu einlesen.
• Den Exponenten der Nebeneinheit bei jeder Währung speichern und für das Runden sowie die Umrechnung zwischen Dezimalbeträgen und Ganzzahlen in der Nebeneinheit verwenden; ihn aus der Liste lesen, nie 2 annehmen.
• Numerische Codes nur verwenden, wenn ein Partner sie verlangt; viele nationale Währungen teilen sich den numerischen Code ihres Landes (CHF und die Schweiz sind beide 756), was in Joins praktisch und in Logs unlesbar ist.
• XXX (keine Währung beteiligt) und XTS (zum Testen) in der Geschäftslogik als explizite Zustände behandeln, nicht als Validierungsfehler.

Stolpersteine

UK ist kein vergebener Ländercode und lässt eine strenge Suche fehlschlagen. Klein- oder gemischtgeschriebene Codes brechen Gleichheits-Joins und Unique Constraints. Ländercodes und ISO-639-Sprachcodes überschneiden sich in der Schreibweise (de steht sowohl für Deutsch als auch, grossgeschrieben, für Deutschland; be steht für Belarussisch und für Belgien), leben aber in unterschiedlichen Spalten. Eine Währungsliste ist keine Liste dessen, was ein Zahlungsanbieter akzeptiert; das getrennt als eigene Konfiguration führen.

Fremdschlüssel und zurückgezogene Codes

Die Tabelle, auf die ein Fremdschlüssel zeigt, und die Tabelle, die neue Eingaben validiert, haben nicht dieselbe Form. Eine Zeile pro Code führen, der jemals existiert hat, mit status (current, withdrawn), valid_from, valid_to sowie der Quellversion; der Fremdschlüssel von den Datenzeilen aus referenziert allein code, sodass historische Datensätze in NLG oder AN nach jedem erneuten Import weiterhin ladbar bleiben. Neue Eingaben mit einem Check Constraint oder einer Anwendungsregel validieren, die nur Codes zulässt, deren Status zum Transaktionsdatum aktuell ist, nicht über den Fremdschlüssel. Erneute Importe fügen dann Zeilen hinzu und schliessen sie ab, löschen sie aber nie, und ein Bericht über alte Daten kann weiterhin jeden Code übersetzen, auf den er trifft.