Ich denke, Need ist ein sehr starkes Wort, und im engeren Sinne benötigen die Tabellen wahrscheinlich keine Ersatzschlüssel .
Wenn es jedoch meine Datenbank wäre, würde ich wahrscheinlich sowieso Ersatzschlüssel hinzufügen. Ich möchte nicht unbedingt, dass mein Datenbankdesign von einer Reihe von Drittanbietern (IATA, ISO) abhängt, unabhängig davon, wie stabil ihre Standards sind. Oder ich möchte mich überhaupt nicht auf einen bestimmten Standard verlassen (gibt es andere Währungscode-Standards? Ich weiß nicht). Ich würde wahrscheinlich meine Tabellen mit Ersatzschlüsseln wie folgt modellieren:
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_id int (PK)| |country_id int (PK) |
|iata_airport_code string | |iso_country_code string |
|icao_airport_code string | +------------------------+
|faa_identifier string |
|address string |
|name string |
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_id int (PK) |
|iso_currency_code string |
|name string |
+-------------------------+
Mit anderen Worten, wenn diese Industriestandardcodes für meine Anwendung nicht von Natur aus wichtig sind, würde ich sie nicht als PK meiner Tabellen verwenden. Sie sind nur Etiketten. Die meisten meiner anderen Tabellen werden wahrscheinlich sowieso Ersatzschlüssel haben, und dieses Setup würde meinem Datenmodell mehr Konsistenz verleihen. Die Kosten für das Hinzufügen der Ersatzschlüssel sind minimal.
Update basierend auf einigen Kommentaren:
Ohne den Kontext der Beispieltabellen zu kennen, ist es unmöglich zu wissen, wie wichtig Dinge wie IATA-Flughafencodes für die Anwendung sind, die die Datenbank verwendet. Wenn IATA-Codes für die gesamte Anwendung von zentraler Bedeutung sind und überall in der Anwendung verwendet werden, ist es möglicherweise die richtige Entscheidung, die Codes nach ordnungsgemäßer Analyse als PK der Tabelle zu verwenden.
Wenn es sich bei der Tabelle jedoch nur um eine Lookup-Tabelle handelt, die in einigen Ecken der App verwendet wird, rechtfertigt die relative Bedeutung der IATA-Codes möglicherweise keinen so wichtigen Punkt in der Datenbankinfrastruktur. Sicher, Sie müssen hier und da ein paar Abfragen zusätzlich mitmachen, aber dieser Aufwand ist möglicherweise trivial im Vergleich zu dem Aufwand, der erforderlich ist, um sicherzustellen, dass Sie die Auswirkungen der IATA-Codes vollständig verstehen Primärschlüsselfeld. In einigen Fällen ist es mir nicht nur egal, sondern ich möchte mich auch nicht um die IATA-Codes kümmern müssen . Der folgende Kommentar von @James Snell ist ein perfektes Beispiel für etwas, über das ich mir keine Sorgen machen möchte, wenn es um die Beeinflussung der PK meiner Tabellen geht.
Auch die Konsistenz im Design ist wichtig. Wenn Sie eine Datenbank mit Dutzenden von Tabellen haben, die alle konsistent Ersatzschlüssel entworfen haben, und dann ein paar Nachschlagetabellen, die Codes von Drittanbietern als PK verwenden, führt dies zu einer Inkonsistenz. Das ist nicht ganz schlecht, erfordert aber zusätzliche Aufmerksamkeit bei der Dokumentation und solche, die möglicherweise nicht gerechtfertigt sind. Es handelt sich um Nachschlagetabellen , nur einen Ersatzschlüssel für die Konsistenz zu verwenden, ist vollkommen in Ordnung.
Update basierend auf weiteren Recherchen:
Ok, die Neugier hat mich gebissen und ich habe mich aus Spaß dazu entschlossen, nach IATA-Flughafencodes zu suchen, beginnend mit den in der Frage angegebenen Links.
Wie sich herausstellt, sind die IATA-Codes nicht so universell und maßgeblich, wie es die Frage vermuten lässt. Nach dieser Seite :
Die meisten Länder verwenden in ihren offiziellen Luftfahrtveröffentlichungen vierstellige ICAO-Codes und keine IATA-Codes.
Darüber hinaus unterscheiden sich IATA- und ICAO-Codes von FAA-Identifizierungscodes , die eine weitere Möglichkeit zur Identifizierung von Flugplätzen darstellen.
Ich möchte damit nicht eine Debatte darüber beginnen, welche Codes besser oder universeller oder autorisierender oder umfassender sind, sondern genau zeigen, warum das Entwerfen Ihrer Datenbankstruktur anhand einer willkürlichen Drittanbieter-ID nicht meine Absicht ist , es sei denn, es gab einen bestimmten geschäftlichen Grund dafür .
In diesem Fall fühle ich meine Datenbank besser strukturiert, stabiler werden würde, und flexibler zu gestalten, indem sie die IATA - Codes zu verzichten (oder eine dritte Partei, potentiell veränderbare Code) als Primärschlüssel Kandidaten und verwenden Sie einen Ersatzschlüssel. Auf diese Weise kann ich auf potenzielle Fallstricke verzichten, die durch die Auswahl des Primärschlüssels entstehen könnten.
