Wird mit char als Primär- / Fremdschlüssel ein nein nein?

Question

Beachten Sie, dass es eine Reihe von Tabellen, die auf „Länder“ verlinken oder „Währungen“ Tabellen.

Für Daten leichter lesbar machen würde Ich mag CHAR-Feld machen mit dem Ländercode (zB USA, GB, AU) und Währung (USD, AUD) ein Primärschlüssel in jeder dieser zwei Tabellen und alle anderen Tabellen verwenden diese CHAR als foregin Taste.

Datenbank ist MySQL mit InnoDB-Engine.

Wird es Performance-Probleme verursachen? Ist es etwas, was ich vermeiden sollte?

Answer 1

Die Leistung ist nicht wirklich das Hauptproblem, zumindest nicht für mich. Das Problem ist, mehr über Surrogat vs natürlichen Schlüsseln.

Ländercodes sind nicht statisch. Sie können sich ändern und tun. Die Länder ändern Namen (zB Äthiopien Eritrea). Sie entstehen, (zB der Zerfall Jugoslawiens und der Sowjetunion) und sie aufhören zu existieren (zB West- und Ost-Deutschland). Wenn dies der ISO-Norm Code-Änderungen geschieht.

Mehr Namensänderungen seit 1990: Länder, Städte und mehr

Surrogate Tasten sind in der Regel besser sein, weil, wenn diese Ereignisse die Schlüssel nicht passieren, nur in der Referenztabelle Spalten ändern tun.

Aus diesem Grunde würde ich eher geneigt, anstatt Land und Währungstabellen mit einem int Primärschlüssel zu erstellen.

Dass gesagt wird, varchar Schlüsselfelder mehr Platz nutzen und bestimmte Leistung Nachteile haben, die wahrscheinlich kein Problem sein wird, wenn Sie eine große Anzahl von Abfragen gerade ausführen.

Für Vollständigkeit, können Sie verweisen href="https://stackoverflow.com/questions/621884/database-development-mistakes-made-by-appdevelopers/621891#621891"> Database Development Fehler gemacht .

Answer 2

James Skidmore der Link ist wichtig, zu lesen.

Wenn Sie sich an Land und Währung Codes sind zu begrenzen (2 und 3 Zeichen, respectively), können Sie sehr gut in der Lage sein, um wegzukommen mit den Spalten deklarieren char (2) und char (3).

Ich würde vermuten, dass nicht tabu sein würde. Wenn Sie eine 8-Bit-Zeichencodierung verwenden, sind Sie in den Spalten suchen, um die Größe von smallint oder MEDIUMINT ist.

Answer 3

Meine Antwort ist, dass es keine klare Antwort. Wählen Sie einfach einen Ansatz innerhalb des Projekts und konsistent sein. Beide haben ihre Vor- und Nachteile.

@cletus macht einen guten Punkt über generierte Schlüssel verwenden, aber wenn Sie in eine Situation kommen, wo die Daten relativ statisch ist, wie Ländercodes, einen generierten Schlüssel für sie scheint zu komplex einzuführen. Trotz der realen Welt der Politik, erscheinen Ländercodes mit und verschwinden wird nicht wirklich viel von einem Problem für die meisten Business-Probleme sein (aber, wenn Ihre Daten aktiv alle 190-210 Länder betrifft, folgen, dass die Beratung).

Mit Ersatzschlüssel universell ist eine gute und beliebte Strategie. Aber denken Sie daran, es kommt als Antwort auf die Modellierung von Datenbanken mit natürlichen Schlüssel für alles. Ack! Öffnen Sie eine 15 Jahre alte Datenbank Buch. natürliche Tasten überall bekommt auf jeden Fall Sie in schwierigen Situationen, wie anfängliche Verständnis für die Problembereiche als falsch erweisen. Sie wollen Konsistenz in Ihren Modellierungspraktiken haben, aber für deutlich unterschiedliche Situationen unterschiedliche Techniken sind in Ordnung.

Ich vermute, dass die Leistung für die meisten modernen Datenbanken auf var (2) Fremdschlüssel wird das gleiche (oder besser) als int Felder aus. Datenbanken sind seit Jahren Textfremdschlüssel unterstützt.

Da wir keine andere Informationen über das Projekt haben, wenn Sie bevorzugt den Ländercodes als Fremdschlüssel zu verwenden ist, und Sie haben die Möglichkeit, dies zu tun, ich würde sagen, es ist in Ordnung. Es wird leichter sein, mit den Daten zu arbeiten. Es ist ein wenig gegen die gegenwärtige Praxis, aber-- in dieser Fall-- es nicht, dass Sie in eine Ecke gehen zurück.