DATENBANKENTWURF - Primärschlüssel für LAND, WÄHRUNG int oder varchar

Question

• Für meine Ländertabelle habe ich den Ländercode als Primärschlüssel verwendet "AU, US, UK, FR" usw.

• Für meine Währungstabelle habe ich den Währungscode als Primärschlüssel verwendet "AUD, GBP, USD" usw.

Ich denke, was ich gemacht habe, ist in Ordnung, aber ein anderer Entwickler möchte, dass ich alle Primärschlüssel in Ganzzahlen ändere, weil der Ländercode, Währungscode sich möglicherweise in Zukunft ändern könnten, sagte er. Wir wissen das einfach nicht, nun in diesem Fall hat er recht, sein Weg ist der sicherste Weg.

Sollte ich die Primärschlüssel sicherheitshalber in Ganzzahlen ändern, anstatt später bereuen zu müssen? Kann ich es nicht einfach so lassen?

Answer 1

Ich würde die ISO-Codes mit Zeichenspalten verwenden.

Wenn sich ein Land jemals teilt, würden neue ISO-Codes entstehen (zum Beispiel SC, WL, EN), aber UK bleibt für historische Daten weiterhin gültig.

Das gilt auch für Währungen. Eine Transaktion im Jahr 2000 würde in der Währung zu diesem Zeitpunkt erfolgen: Französische Francs, Deutschmarks, Belgische Bananen, aber nicht Euro.

Answer 2

Ich würde sagen, dass die "Geburt einer Nation" oder das Verschwinden einer Währung - insgesamt gesehen - ein ziemlich seltenes Ereignis ist, das nicht wahrscheinlich ist, mehrmals im Jahr, jedes Jahr zu passieren.

In diesem Sinne denke ich, dass es in Ordnung wäre, die von der ISO definierten Länder- und Währungscodes für Ihren Primärschlüssel zu verwenden.

Ja, wenn etwas im Euroraum passiert, oder wenn ein weiteres Land in zwei Teile gespalten wird, müssten Sie etwas manuelle Aufräumarbeiten durchführen - aber das müssten Sie auch bei einem INT tun. In einem solchen Fall würde ich argumentieren, dass ein künstlicher Surrogatschlüssel (wie ein INT) nur zusätzlichen Aufwand verursacht und wirklich nicht dazu beiträgt, die Dinge einfacher/klarer zu halten.

Da diese Codes wirklich kurz sind und typischerweise alle die gleiche Länge haben, würde ich jedoch empfehlen, ein CHAR(3) oder CHAR(5) zu verwenden - es ergibt keinen Sinn, VARCHAR für einen so kurzen String zu verwenden, und außerdem verhalten sich VARCHAR als variable Felder ganz anders (und nicht "besser" in Bezug auf die Leistung) als feste Felder wie INT oder CHAR

Answer 3

Von einem logischen Standpunkt aus bedeutet das Hinzufügen eines Surrogats zusätzliche Spalten, zusätzliche Schlüsselbeschränkungen und komplexere Logik zum Abfragen und Manipulieren der Daten. Das ist eine Sache, die man berücksichtigen sollte.

Von einem physischen Standpunkt aus wird in SQL Server ein INTEGER-Schlüssel mehr als doppelt so viel Platz einnehmen wie ein CHAR(2) oder CHAR(3). Das bedeutet, dass Ihre Referenztabellen und Indexes größer werden. Es macht auch Updates zu diesen Fremdschlüsselwerten viel teurer. Ich kenne Ihre Daten nicht, aber es scheint durchaus möglich zu sein, dass die Referenzdaten in diesen Fremdschlüsselspalten häufiger aktualisiert werden als die Länder- und Währungscodes in der übergeordneten Tabelle. Im Gegensatz dazu ändern sich die ISO-Codes für Währung und Land fast nie, sodass dies wohl kaum ein Problem darstellt. Durch die Umstellung auf INTEGER-Schlüssel könnten die Kosten für das Aktualisieren dieser Fremdschlüsselwerte durchaus zunehmen.

Wenn Sie eine solche Änderung als Leistungssteigerung in Betracht ziehen, empfehle ich Ihnen dringend, sorgfältig zu prüfen, ob INTEGER-Schlüssel die Aktualisierungen dieser Werte teurer oder kostengünstiger machen werden. Ich empfehle Ihnen, Personen zu ignorieren, die sagen "immer X machen". Dogma ist keine Hilfe bei der Datenbankgestaltung. Evaluieren Sie, was die tatsächlichen Auswirkungen in der Praxis sein werden, und treffen Sie Ihre Entscheidung entsprechend.

Answer 4

Ich denke, dein System wird zehn Mal veraltet sein, bevor der ISO-Standard für Länder- und Währungscodes dies tut.

Also sehe ich wirklich keinen Vorteil darin, 01010101, 01010011 oder 21843 anstelle von "US" zu verwenden.

Answer 5

Solange alle Fremdschlüssel, die auf diese Primärschlüssel verweisen, mit ON UPDATE CASCADE deklariert sind, wen kümmert es, wenn sich diese Codes ändern?

Es gibt einen zusätzlichen Vorteil beim Abfragen einer der referenzierenden Tabellen - wenn Sie nur den Länder-/Währungscode benötigen, dann müssen Sie nicht mit diesen Tabellen verknüpfen - Sie haben den Code bereits in diesen Tabellen enthalten.

---

Und wenn Sie sich doch für einen INT-Surrogat entscheiden, denken Sie bitte daran, weiterhin einen eindeutigen Constraint auf diese Spalten zu setzen - sie sind weiterhin ein echter Schlüssel für diese Tabellen.