SQL: Primary / Foreign Key & References

misterbecks

misterbecks

Aktives Mitglied
Thread Starter
Dabei seit
06.11.2004
Beiträge
2.336
Reaktionspunkte
24
Ich arbeite mich gerade in SQL ein, allerdings fehlen mir für die o.g. Begriffe noch Verwendungsmöglichkeiten und damit das Verständnis.

In welchen Zusammenhang wird ein PRIMARY KEY gebraucht?
FOREIGN KEY: Nutzen?
REFERENCES: Nutzen, wenn nicht mit ON DELETE CASCADE / SET NULL verbunden?
 
Primary Key (Primärschlüssel) ist ein einmaliger Eintrag eines Datensatzes, damit man ihn zweifelsfrei erkennen (und ansprechen) kann. Zum Beispiel eine automatisch hochzählende ID.

Ein Foreign Key (Fremdschlüssel) ist ein Feld in der Tabelle, der auf einen anderen Primary Key verweist.

Beispiel:

Tabelle: Kunde
Felder:
kunde_id <-- Primary Key
kunde_name
...

Tabelle: Rechnungsadresse
Felder:
rechnungsadress_id <-- Primary Key
rechnungsadress_kunde_id <-- hier Foreign Key
...

Ansonsten findest Du hier noch weiterführende Informationen.
 
master_p schrieb:
Primary Key (Primärschlüssel) ist ein einmaliger Eintrag eines Datensatzes, damit man ihn zweifelsfrei erkennen (und ansprechen) kann. Zum Beispiel eine automatisch hochzählende ID.

Ein Foreign Key (Fremdschlüssel) ist ein Feld in der Tabelle, der auf einen anderen Primary Key verweist.

Ok, das war klar. Aber wie sieht es mit der Verwendung aus?
Tabelle: Kunde
Felder:
kunde_id <-- Primary Key
kunde_name

Code:
UPDATE kunde
SET kunde_name = 'Hans'
WHERE kunde_id = 10;

Auf kunde_id kann ich doch auch so zugreifen, wo liegt der Vorteil bei einem Primärschlüssel?
 
Die Summe aus Primary Keys und Referenzen
wird unter anderem dazu genutzt vom Datenbank System
die Logische Konsistenz der Daten zu erzwingen.

Stell dir bei dem obigen Beispiel vor das es den PrimaryKey KUNDEN_ID nicht geben würde.

Dann wäre es möglich das z.B. durch einen Programmfehler 2 Kunden mit der ID 10 angelegt werden. Welcher ist dan bei der Dereferenzierung nun der richtige ? Müller oder Meier ;-)

LG Worf
 
worf schrieb:
Stell dir bei dem obigen Beispiel vor das es den PrimaryKey KUNDEN_ID nicht geben würde.
Dann wäre es möglich das z.B. durch einen Programmfehler 2 Kunden mit der ID 10 angelegt werden. Welcher ist dan bei der Dereferenzierung nun der richtige ? Müller oder Meier ;-)
Das ist logisch und erklärt es. Würde aber dann nicht einfaches UNIQUE reichen?

Aber die Bedeutung der Referenz ohne die o.g. Bedingungen ist noch nicht ganz klar.....
 
Die Primärschlüssel dienen wirklich zunächst dazu, den Datenbank-Satz eindeutig zu gestalten. Einige Datenbanksysteme -e.g. SQL Server- nutzen diese Information jedoch auch, um die Daten in einer gewissen Reihenfolge im Datenbankspeicher abzulegen.

Kurzum: jede Tabelle sollte um einen Primärschlüssel verfügen.

Die Fremdschlüssel sind nun dazu da, dass in der o.g. Bestellungstabelle keine Kunden-ID eingetragen wird, die in der Kunden-Tabelle nicht existiert. Hier geht es also primär um die Sicherstellung der Konsistenz der Daten. Ein Versuch eine nicht vorhandene Kunden-ID einzustellen, lehnt das Datenbanksystem mit einer Fehlermeldung ab.

Über die References-Schlüsselwörter kann dann noch spezifiziert werden, was das Datenbank-System machen soll, wenn der Master-Satz gelöscht wird. Im obigen Fall: was passiert mit den Sätzen in der Bestellung-Tabelle, wenn der Kunde gelöscht wird ? Sollen a) alle Bestellungs-Sätze zu diesem Kunden auch gelöscht werden (CASCADE DELETE) oder b) sollen die Bestellungs-Sätze im Kunden-ID Feld mit NULL gefüllt werden etc. pp. Ausserdem kann angegeben werden, dass eine Änderung der Kunden-ID (Primärschlüssel auf der Kundentabelle) automatisch auch alle referenzierten Sätze in der Bestellungstabelle mit aktualisiert (CASCADE UPDATE)....

gruss
andi
 
misterbecks schrieb:
Das ist logisch und erklärt es. Würde aber dann nicht einfaches UNIQUE reichen?

Klar, dann kannst Du aber auch nur einen „Müller“ anlegen.
 
Jakob schrieb:
Klar, dann kannst Du aber auch nur einen „Müller“ anlegen.


Das ist so nicht richtig :p

Schliesslich wird die ID als Primary Key Hinterlegt nicht der Name.

Unter Umständen verhindert der Primary Key zusätzlich zur
Eindeutigkeit der Werte auch noch das Anlegen eines Datensatzes mit Null
Wert in der PK Spalte. Also ein Kunde ganz Ohne ID.

Auch das könnte recht hilfreich sein.
ORACLE z.B. macht das meines Wissens Nach so.
Dort wird das z.B. erzwungen weil ORACLE Sätze mit Null in einer Schlüsselspalte nicht im Index führt.

Würde der Primary Key nun z.B. Null Werte zulassen dann müsste der Server unter Umständen die gesammte Tabelle lesen um zu prüfen ob nicht doch noch irgendwo ein Datensatz rummliegt der zufällig in der PK Spalte keine Daten (eben Null) enthält.

Warum kannst du die Primary Key Definition nicht einfach hinnehmen so wie Sie ist?

Die ganzen gelerten rund um Cod werden schon gewusst haben was sie da machen.

Und der Ansatz das man jeder Tabelle zumindest einen Primary Key gönnen sollte bringt oftmals viele Vorteile.

LG Worf
 
worf schrieb:
Das ist so nicht richtig

Hatte mich verlesen. Ich dachte er möchte statt einer Primary Key-Spalte einfach ein UNIQUE auf die Namen legen und dadurch Eindeutigkeit wahren.

Da dem nicht so ist… über was reden wir hier jetzt überhaupt?

Primary und foreign keys können Beziehungen zwischen Tabellen herstellen und so Konsistenz wahren. Wenn Du nur eine Tabelle hast, würde afaik theoretisch ein UNIQUE und ein INDEX auf die pseudo-primary key-Spalte reichen.

Aber das ist eher Haarspalterei.
 
Ähm, jetzt kommt glaube ich so einiges durcheinander....

worf schrieb:
Warum kannst du die Primary Key Definition nicht einfach hinnehmen so wie Sie ist?
Das kann ich ohne Probleme (habe auch nie das Gegenteil behauptet), ich würde es nur gerne komplett verstehen.
worf schrieb:
Und der Ansatz das man jeder Tabelle zumindest einen Primary Key gönnen sollte bringt oftmals viele Vorteile.
Und genau um diese Vorteile geht es hier!

Jakob schrieb:
Hatte mich verlesen. Ich dachte er möchte statt einer Primary Key-Spalte einfach ein UNIQUE auf die Namen legen und dadurch Eindeutigkeit wahren.
Du hast dich nicht verlesen, bzw. nur teilweise. Ich möchte UNIQUE auf die Kundennummer legen, um das
worf schrieb:
Dann wäre es möglich das z.B. durch einen Programmfehler 2 Kunden mit der ID 10 angelegt werden.
zu verhindern. Gleicher Effekt, oder?

Jakob schrieb:
Aber das ist eher Haarspalterei.
Nicht ganz. Es geht um den Sinn und Nutzen einer Funktion.

andi.reidies schrieb:
(...) Über die References-Schlüsselwörter kann dann noch spezifiziert werden, was das Datenbank-System machen soll, wenn der Master-Satz gelöscht wird. Im obigen Fall: was passiert mit den Sätzen in der Bestellung-Tabelle, wenn der Kunde gelöscht wird ? Sollen a) alle Bestellungs-Sätze zu diesem Kunden auch gelöscht werden (CASCADE DELETE) oder b) sollen die Bestellungs-Sätze im Kunden-ID Feld mit NULL gefüllt werden etc. pp. Ausserdem kann angegeben werden, dass eine Änderung der Kunden-ID (Primärschlüssel auf der Kundentabelle) automatisch auch alle referenzierten Sätze in der Bestellungstabelle mit aktualisiert (CASCADE UPDATE)....

Ok, gut erklärt.
 
Zurück
Oben Unten