Benötigen diese spezifischen Tabellen Ersatzschlüssel?

Question

Hintergrund

Ich habe diese Tische

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

Flughafencode ist der IATA (International Air Transport Association) Flughafencode, Sie können sie in Ihren Gepäckanhängern sehen, wenn Sie mit dem Flugzeug reisen.

Ländercode ist der ISO 3166-1 A3-Standard-Ländercode, man kann sie bei den Olympischen Spielen sehen.

Währungscode ist der IS0 417 Standard-Währungscode mit drei Zeichen, Sie können sie auf den Schautafeln für internationale Währungsumtausche sehen.

Fragen

Sind diese natürlichen PKs gut genug?

Ist die Verwendung weltweit anerkannter Standards, die von ganzen Branchen akzeptiert werden, für PKs ausreichend?

Brauchen diese Tabellen Ersatzzeichen, egal was passiert?

Answer 1

nein, sie tun es nicht.Diese Schlüssel sind definitiv gut genug!

Sie sind einzigartig, nicht selten wird sich ändern, und sinnvoll , was ein Schritt über einen Ersatztasten ist.Das ist so ziemlich die Definition einer guten PK.

Die Einschränkungen über PKS, die unveränderlich und numerisch sind, sind nicht Teil des relationales Modell (Codds) oderbeliebiger SQL-Standard (ANSI oder andere).

Answer 2

Ich denke, brauche ein sehr starkes Wort ist, und in einem strengen Sinne, die Tische wahrscheinlich nicht brauchen Surrogatschlüssel .

Wenn es jedoch meine Datenbank wäre, würde ich wahrscheinlich trotzdem Surrogate-Schlüssel hinzufügen. Ich möchte nicht unbedingt, dass mein Datenbankdesign von einem Bündel Dritter (IATA, ISO) abhängig ist, unabhängig davon, wie stabil ihre Standards sind. Oder ich möchte vielleicht nicht auf einen bestimmten Standard abhängen (gibt es andere Währungscode-Standards? Ich weiß es nicht). Ich würde wahrscheinlich meine Tabellen mit Ersatztasten wie so modellieren:

generasacodicetagpre.

Mit anderen Worten, es sei denn, diese Industriestandardcodes sind inhärent wichtig an meine Anwendung, würde ich sie nicht als PK von meinen Tabellen verwenden. Sie sind nur Etiketten. Die meisten meiner anderen Tabellen werden wahrscheinlich sowieso Surrogatschlüssel haben, und dieses Setup würde meinem Datenmodell Konsistenz hinzufügen. Die Kosten für das Hinzufügen von 'Hinzufügen der Ersatztasten sind minimal.

update basierend auf einigen der Kommentare:

Ohne den Kontext der Beispieltabellen zu kennen, ist es unmöglich zu wissen, wie wichtig wie wichtige Flughafen-Codes iata mit der Datenbank an der Anwendung sind. Wenn IATA-Codes offensichtlich wichtig sind und in der gesamten Anwendung durchdringlich eingesetzt und verwendet werden, kann es nach der richtigen Analyse die richtige Entscheidung sein, die Codes als PK der Tabelle verwenden.

Wenn der Tisch jedoch nur eine Nachschlagetabelle ist, die in einigen Ecken der App verwendet wird, ist die relative Bedeutung der IATA-Codes möglicherweise nicht einen solchen prominenten Punkt in der Datenbankinfrastruktur rechtfertigen. Sicher, Sie müssen vielleicht einen zusätzlichen Beitritt in einigen Abfragen hier und dort machen, aber diese Bemühungen könnten im Vergleich zu den Bemühungen, die es dauern würde, um die Forschung zu ergreifen, um sicherzustellen, dass Sie die Auswirkungen der Erstellung der IATA-Codes vollständig verstehen Primärschlüsselfeld. In einigen Fällen interessiert es mir nicht nur, aber möchte ich nicht um die IATA-Codes kümmern müssen. @James Snells Kommentar unten ist ein perfektes Beispiel für etwas, das ich mir vielleicht nicht kümmern muss, um die Pk meiner Tabellen zu beeinträchtigen.

Auch Konsistenz im Design ist wichtig. Wenn Sie über eine Datenbank mit Dutzenden von Tabellen verfügen, die alle konstante Ersatztasten konstruiert haben, und dann ein paar Nachschlagetabellen, die 3RD-Partei-Codes als PK verwenden, die ein Inkonsistenz einleiten. Das ist nicht insgesamt schlecht, aber es erfordert zusätzliche Aufmerksamkeit in der Dokumentation und so, dass dies nicht garantiert werden kann. Sie sind Lookup-Tabellen für die Güte willen, nur mit einem Ersatztasten für Konsistenz ist vollkommen in Ordnung.

update basierend auf der weiteren Forschung:

ok, neugierige, neugierig, war ich und ich beschlossen, mit den in der frage bereitgestellten Links zu erforschen.

Wenn sich herausstellt, sind die IATA-Codes nicht so universell und autoritär, da die Frage sie zu sein macht. Laut diese Seite :

Die meisten Länder verwenden vier-charaktere ICAO-Codes , keine IATA-Codes, in ihrer offizielle aeronautische Publikationen.

Darüber hinaus unterscheiden sich IATA-Codes und ICAO-Codes von FAA-Identifier-Codes , das sind noch eine andere Möglichkeit, Flugplätze zu identifizieren.

Mein Punkt, um diese zu bringen, ist nicht, eine Debatte darüber zu beginnen, welche Codes besser oder universeller oder autoritärer oder umfassenderer, aber genau zeigen, warum das Entwerfen Ihrer Datenbankstruktur um einen beliebigen 3rd-Partei-Kennung nicht etwas ist Wählen Sie, zu tun, es sei denn, es gab einen bestimmten Geschäftsgrund, um dies zu tun .

In diesem Fall ist ich fühle mich meine Datenbank wäre besser strukturiert, stabiler und flexibler, indem er die IATA-Codes (oder einen Drittanbieter, möglicherweise wechselbarer Code) als Primärschlüsselkandidat angeht und verwenden Sie einen Surrogatschlüssel. Dadurch kann ich auf mögliche Fallstricke verzichten, die aufgrund der primären Schlüsselauswahl auftauchen könnten.

Answer 3

Es ist zwar in Ordnung, Ersatzschlüssel in den Feldern zu haben, und daran ist auch nichts auszusetzen. Es sollte jedoch die Größe der Indexseite selbst berücksichtigt werden.

Da es sich um eine relationale Datenbank handelt, werden Sie viele Verknüpfungen durchführen und ein Ersatzschlüssel eines numerischen Typs könnte die Handhabung der Datenbank erleichtern, d. h.Die Größe der Indexseite wird kleiner und die Suche dadurch schneller.Wenn es sich um ein kleines Projekt handelt, spielt das keine Rolle und Sie kommen ohne Probleme zurecht. Je größer die Anwendung wird, desto mehr sollten Sie jedoch Engpässe reduzieren.

Wenn Sie einen BIGINT-, INT-, SMALLINT-, TINYINT- oder einen ganzzahligen Datentyp haben, können Sie sich später möglicherweise einige Probleme ersparen.

Nur meine 2 Cent

AKTUALISIEREN:

Kleines Projekt – genutzt von ein paar, vielleicht sogar ein paar Dutzend Leuten.Kleinformatiges Demoprojekt, Projekt für den persönlichen Gebrauch, etwas, das Sie Ihrem Portfolio hinzufügen können, wenn Sie Ihre Fähigkeiten ohne Erfahrung präsentieren, und dergleichen.

Großes Projekt – täglich von Tausenden, Zehntausenden, Millionen Benutzern genutzt.Etwas, das Sie für ein nationales/internationales Unternehmen mit einer riesigen Benutzerbasis entwickeln würden.

Normalerweise werden einige ausgewählte Datensätze häufig ausgewählt und der Server speichert die Ergebnisse für einen schnellen Zugriff zwischen. Hin und wieder müssen Sie jedoch auf einen weniger verwendeten Datensatz zugreifen, woraufhin der Server auf den Index zugreifen muss Seite.(Im obigen Beispiel mit den Flughafennamen fliegen die Leute oft mit inländischen Fluggesellschaften, sagen wir Chichago -> Los Angeles, aber wie oft fliegen die Leute von Boston -> Simbabwe)

Wenn VARCHAR verwendet wird, bedeutet dies, dass der Abstand nicht einheitlich ist, es sei denn, die Daten haben immer die gleiche Länge (an diesem Punkt ist ein CHAR-Wert effektiver).Dadurch wird die Suche im Index langsamer, und da der Server ohnehin schon damit beschäftigt ist, Tausende und Abertausende Abfragen pro Sekunde zu verarbeiten, muss er nun Zeit damit verschwenden, einen uneinheitlichen Index zu durchsuchen und das Gleiche noch einmal bei den Joins zu tun (was langsamer ist als regelmäßige Auswahlen für eine nicht optimierte Tabelle, nehmen Sie DW als Beispiel, wo es so wenige Verknüpfungen wie möglich gibt, um den Datenabruf zu beschleunigen).Auch wenn Sie UTF verwenden, kann dies auch zu Problemen mit der Datenbank-Engine führen (ich habe einige Fälle gesehen).

Persönlich kann ich aus eigener Erfahrung sagen, dass ein richtig organisierter Index die Geschwindigkeit eines Joins um ca. 70 % erhöhen kann, und ein Join für eine Integer-Spalte kann den Join um bis zu ca. 25 % beschleunigen (abhängig von den Daten). .Wenn die Haupttabellen zu wachsen beginnen und diese Tabellen darauf verwendet werden, möchten Sie lieber, dass ein ganzzahliger Datentyp die Spalte mit ein paar Bytes belegt, statt dass ein VARCHAR-/CHAR-Feld mehr Platz einnimmt.Es kommt darauf an, Speicherplatz zu sparen, die Leistung zu steigern und die Gesamtstruktur einer relationalen Datenbank zu verbessern.

Außerdem erwähnte James Snell:

Primärschlüssel müssen außerdem unveränderlich sein, was bei IATA-Flughafencodes definitiv nicht der Fall ist.Sie können nach Belieben der IATA geändert werden.

Wenn Sie dies berücksichtigen, müssten Sie lieber einen Datensatz aktualisieren, der an eine Zahl gebunden ist, als diesen einen Datensatz plus alle Datensätze in der Tabelle, mit der Sie verknüpfen, aktualisieren zu müssen.

Answer 4

Wenn Sie die "I-Annäherung" -Surrogat-Schlüssel verwenden ", können Sie diese Art von Sorge umgehen. Das ist vielleicht nicht eine gute Sache, weil es wichtig ist, Ihren Daten einige Gedanken zu geben, aber es rettet sicherlich viel Zeit, Energie und Anstrengung. Wenn jemand eine Annahme in diese Regel übernehmen würde, qualifizieren sich die aufgelisteten Beispiele sicherlich, weil es ein nahes "Akt des Kongresses" einnimmt, um die Änderung vorzunehmen.

Ad-hoc-Anfragen einer Datenbank mit diesen natürlichen Tasten ist sicherlich hilfreich. Erstellen von Ansichten, die dasselbe tun, indem Sie die Lookup-Tabellen einbeziehen, können ebenso gut funktionieren. Moderne Datenbanken machen einen viel besseren Job mit dieser Art von Zeug bis zu dem Punkt, an dem es wahrscheinlich keine Rolle spielt.

Es gibt einige Fälle, die für die USA spezifisch sind, in denen Standards drastisch geändert wurden: Postleitzahl wurde von 5 - 9 Ziffern erweitert, steuerliche Abkürzungen zu einem konsistenten 2 Buchstaben und beseitigen Sie den Zeitraum (erinnern Sie sich, wenn Illinois krank war.?), Und der größte Teil der Welt machte sich mit Y2k umgehen. Wenn Sie eine Echtzeit-App mit Daten verbreiten, die auf der ganzen Welt gespreizbar sind, sind Cascading-Updates nicht die beste Idee, aber sollten wir nicht alle an Orten arbeiten, die solche Herausforderungen stellen? Mit diesem Datensatz können Sie es für sich selbst testen und mit einer schwierigen Antwort kommen.