Allgemeine Frage zu Lookup - Tables

Ishildur

Hallo zusammen
Ich habe da eine kleine Frage bezüglich Lookup-Tables, die mich sehr beschäftigt und habe ich oft Tabellen, welche an sich nur eine einzige Spalte benötigen (beispielsweise eine Ländertabelle). Ich sehe oft, dass in solchen Fällen einfach der Name des Landes als Primärschlüssel verwendet wird und gut ist. Aber ist dies Sinnvoll?

Variante A:

CREATE TABLE Country(
Name VARCHAR(32) NOT NULL PRIMARY KEY
);

Variante B:

CREATE TABLE Country(
CountryID INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name VARCHAR(32) NOT NULL UNIQUE
);

Was ist Sinnvoller?

Lg

P.S.
Eventuell gibt es ja noch eine Variante C oder D?

Unix-Tom

Variante 2 ist sinnvoller.
Was möchte man mit einer Tabelle wo der Name drin steht bezwecken?
Klar kann man das so machen wenn man z.B. ein Dropdown füllen möchte.
Da das Land aber auch in anderen Tabellen gebraucht wird schreibt man da wieder den Namen als VARCHAR rein?
Nein!!!
Man schreibt gem. Normalisierung die ID rein.

hustbaer

Unix-Tom schrieb:

Da das Land aber auch in anderen Tabellen gebraucht wird schreibt man da wieder den Namen als VARCHAR rein?
Nein!!!
Man schreibt gem. Normalisierung die ID rein.

Keine Normalform sagt dass das nicht OK wäre. Vorausgesetzt man betrachtet den Ländernamen als Key (was nicht unüblich ist!).

Welchen Candidate-Key ich mir als Primary-Key aussuche ist doch immernoch meine Entscheidung.

Falls du anderer Meinung sein solltest, bitte gib mir einen Link wo das erklärt ist, denn ich kenne wirklich keinen Artikel der etwas anderes behauptet.

----

Es ist aber aus anderen Gründen keine gute Idee.

Der Ländername könnte sich ändern (Tippfehler oder warum auch immer). Natürlich können viele aktuelle DBMS' Foreign-Key Spalten automatisch anpassen. Allerdings sollte man als Key IMO immer nur unveränderliche Daten verwenden. Ein vollkommen bedeutungsfreier Integer ist da praktisch. Der Ländername wird dadurch zu einem Attribut, und darf frei geändert werden.
Performance. Strings vergleichen/sortieren/indizieren etc. ist *sehr* langsam. Viele machen den Fehler zu denken "naja, vergleicht er halt 32 Byte statt 4, ist ja nicht so schlimm". In Wirklichkeit ist ein String-Vergleich in bei den meisten DBMS' wesentlich aufwändiger. Es müssen aus den eigentlichen Strings erstmal Sortkeys erstellt werden, und das ist recht aufwändig. Die Sortkeys können dann verglichen werden (das ist der vergleichsweise billige Teil).
http://en.wikipedia.org/wiki/Collation
http://www.unicode.org/unicode/reports/tr10/

----

Also nochmal: die (sehr übliche) Vorgehensweise, "Integer-IDs" zu vielen Tabellen dazuzupacken, und diese dann zum Primary-Key zu erklären, hat zwar oft viele Vorteile, aber nichts mit Normalisierung zu tun.