Sinn von Primärschlüsseln bei DatenBanken
Ich glaube, dass ich nicht wirklich begriffen habe, wofür Primärschlüsseln bei Datenbanken gebraucht werden.
Primärschlüsseln werden genutzt, um eine Zeile einer Datenbanktabelle eindeutig zu machen. Hierbei wird eine Spalte mit Werten die sich nicht wiederholen und nicht NULL sind häufig als Primary Key verwendet oder das Datenbanksystem erzeugt sich intern eine solche Spalte.
Nur:
Wenn man eine Spalte hat, die von Natur aus eindeutige Werte besitzt, benötigt man doch keinen Primary Key dafür? Man kann doch einfach über die Spalte joinen oder selecten oder habe ich etwas falsch verstanden?
8 Antworten
Hello there,
ich erklärs dir gerne. Primärschlüssel haben mehrere Funktionen. Wie du schon erkannt hast, dienen sie insbesondere dazu, einen Datensatz eindeutig zu machen. Nun sagst du natürlich.....was ist denn, wenn ich einen Wert habe, der von Natur aus, eindeutig ist...? Ja, dann kannst du auch DEN als Primärschlüssel nehmen. Bis auf wenige Ausnahmen brauchst du in JEDER Datenbanktabelle einen Primärschlüssel. In der Regel ist das einfach eine ID, die hochzählt, das heißt jeder Eintrag hat eine Nummer von 1 bis n. Dies ist nötig um die Integrität der Daten und die Eindeutigkeit der Datensätze zu gewährleisten. Wenn du aber einen natürlichen Primärschlüssel hast, kannst du den natürlich auch verwenden. Beispielsweise eine Personalausweisnummer, ein KFZ-Zeichen oder ähnliches. Du hast auch die Möglichkeit, einen sogenannten zusammengesetzten Primärschlüssel zu verwenden, das heißt du machst aus zwei oder mehr Spalten, von denen jede einzeln nicht zwingend eindeutig ist einen Primärschlüssel, bei denen die zwei Spalten zusammen ein jeweils eindeutiges Wertepaar generieren. Meinetwegen der genaue Zeitstempel des Eintrags in Kombination mit der Person, die den Eintrag erstellt hat. Eine Person kann ja gleichzeitig nicht mehrere Einträge hinzufügen, sondern nur nacheinander.
Der nächste Sinn des Primärschlüssels, das wurde ja schon erwähnt ist die Indizierung von Einträgen. Indizes sind dazu da, dass die Datenbank schneller durchsucht werden kann. Der Primärschlüssel ist automatisch ein Index, du kannst aber zusätzlich weitere Spalten zu Indizes machen. Du bekommst dafür gerade in sehr großen Datenbanken die Suchanfragen deutlich schneller ausgeführt, weil du über Strukturen, sogenannte "B-Bäume" die Informationen besser abspeichern kannst, das wird intern durchgeführt, bezahlen tust du diese Vorgehensweise mit deutlich mehr Festplattenspeicherbedarf.
Der dritte und fast wichtigste Zweck von Primärschlüsseln ist die Verknüpfung von Tabellen. SQL-Datenbanken sind sogenannte Relationale Datenbanken, das heißt die einzelnen Tabellen sind über Beziehungen (Relationen) miteinander verbunden. Dazu kannst du in einer Tabelle einen sogenannten Fremdschlüssel deklarieren. Dieser Fremdschlüssel ist immer ein Verweis (Referenz) auf einen Primärschlüssel in einer anderen Tabelle. Und deshalb sind Primärschlüssel auch notwendig, um in anderen Tabellen korrekt auf die Zieltabelle verweisen zu können.
Einfaches Beispiel: Wenn du eine Schulklasse hast, dann hat die Klasse mehrere Schüler. Das heißt wenn du eine Tabelle Klassen hast und eine Tabelle Schüler, dann hätte jeder Schüler einen Fremdschlüssel "Klasse" und der würde auf den Primärschlüssel der Tabelle "Klasse" zeigen, so könnte jedem Schüler eindeutig seine Klasse zugewiesen werden. In der Tabelle Klasse könnten zusätzliche Informationen gespeichert werden, etwa der Name des Klassenleiters, der Fachzweig der Klasse und so weiter. All diese Informationen wären dann auch den Schülern dieser Klasse über die Beziehung Tabelle Klasse -Tabelle Schüler zuordbar.
Ein letzter Sinn, der ist aber nicht so sehr wichtig, ist die Kennzeichnung von sogenannten Ranges bei der Partitionierung von Tabellen. Wenn du sehr sehr große Datenbanken hast, möchtest du vielleicht die Tabellen strukturieren und vielleicht nicht immer die gesamte Tabelle durchsuchen, sondern immer nur einen bestimmten Teilbereich. Dazu kannst du Partitionen anlegen. Du kannst dann meinetwegen sagen:
Partition 1: Einträge von 1 bis 25000 Parition 2: Einträge von 25001 bis 50000 ....
Hoffe das beantwortet deine Frage ausführlich genug. Ich würde mich über einen Stern freuen.
MfG
Alex
Die erste Antwort ist doch schon super...
Als professioneller Datenbankentwickler möchte ich gern ergänzen, dass man besser wirklich immer einen künstlichen Primary Key ergänzt, auch wenn man schon eigentlich eindeutige Spalten hat. Es vereinfacht die Struktur (PK ist z.B. Immer die erste Spalte und heißt auch immer gleich, z.B. Id) und kann später zum Retter werden, wenn durch mehr Daten oder einem gewünschten Update auf die 'eigentlich' eindeutige Spalte die Eindeutigkeit plötzlich verloren geht.
Wenn man bis dahin auf den künstlichen PK verzichtet hat, wäre es nach einer solchen Aktion Zeit, das Datenmodell und auch existierende Abfragen und Programmcode komplett umzubauen, da alle relational an besagte Tabelle angebundene Tabellen geändert werden müssten. Wenn man gleich mit künstlichen PKs arbeitet kann das nicht passieren.
Ich hoffe das ist nachvollziehbar :-)
Auch wenn Deine Überlegung manche vor den Kopf stößt, so verkehrt ist sie nicht. Denn eine Verknüpfung funktioniert grundsätzlich auch ohne Primärschlüssel und wenn die betreffende Spalte eindeutig ist, würde auch das richtige Ergebnis dabei rauskommen. Statt mittels Join könnte man auch mit WHERE verknüpfen, was genauso gut geht. Nur: Wenn aus irgendeinem Grund die Eindutigkeit nicht mehr gegeben wäre, käme was Falsches dabei raus ohne dass man es merkte. Mit einem Primärschlüssel kennt sich die Datenbank aus und hat volle Kontrolle über den Ablauf. Damit im Zusammenhang stehen auch die Fremdschlüssel, mit denen man der Datenbank mitteilt, dass damit eine bestimmte Bedeutung verbunden ist, die es zu beachten gibt. Ohne Fremdschlüssel wüsste die Datenbank das nicht und könnte den Ablauf zwar durchführen, aber eben unkontolliert.
Wenn man eine Spalte hat, die von Natur aus eindeutige Werte besitzt, benötigt man doch keinen Primary Key dafür?
Generell hast Du recht, wenn Du eine Spalte hast die von "Natur aus" eindeutige Werte besitzt, bräuchtest Du theoretisch keinen Primary Key. Du kannst auch ohne weiteres Tabellen ohne Primary Key erstellen wenn Du lustig bist.
Das Problem ist das Du dann selbst dafür verantwortlich bist dafür zu sorgen das Einträge nur einmal vorkommen.
Wenn Du keinen Primary Key definierst wird dich Die Datenbank nicht warnen / keinen Fehler schmeißen wenn Du versuchst nochmals eine Zeile mit dem "von Dir selbst" verwalteten Primary Key einzufügen.
Sagen wir Du hast eine Tabelle Bankkonten wo die Kontonummer ("von Natur aus eindeutig??") der Primary Key ist. Ein Bankkonto sollte nur einmal existieren.
Du fügst jetzt nochmals ein Bankkonto mit der selben Kontonummer ein. Wenn Du einen Primary Key hast und Du versuchst nochmals ein Bankkonto mit der selben Nummer aber eventuell einem anderen Besitzer und Betrag anzulegen, wird Dir die Datenbank sagen dass das nicht geht weil die Kontonummer schon existiert. Hast Du keinen Primary Key bei der Tabellendefinition festgelegt so kannst Du beliebig viele Einträge mit der selben Kontonummer anlegen, was nicht sein sollte, ohne das Dich die Datenbank warnt.
Damit kannst Du je nach Daten ganz üble Dateninkonsistenzen erzeugen. Von daher solltest Du auch die Sicherheitsmechanismen die Dir die Datenbank von haus aus bereitstellt auch nutzen.
Weiterhin nimmt man normalerweise eindeutige Ids als Primary Key anstatt zusammengesetzen Primary Key, da man sich damit bei der Verknüpfung mit anderen Tabellen über Foreign Keys leichter tut.
Genau so kannst Du auch darauf verzichten bei der Tabellendefinition explizit Foreign Keys zu definieren. Hier hebelst Du aber auch wieder bestimmte prüfmechanismen aus die Dir die Datenbank bereitstellt um Dateninkonsitenzen zu vermeiden die z.B. durch Löschvorgänge entstehen können. Weiterhin können dann einige Tools z.B. aus einer bestehenden Datenbank automatisch entsprechende Diagramme mit den Tabellenverknüpfungen generieren was sehr hilfreich sein kann. Ohne die Foreign Keys ist dies nicht möglich und Du musst Dir die Verknüpfungen selbst irgendwie herleiten falls das eventuell durch entsprechende Namensgebung möglich ist kann. Ohne diese kann das aber auch ein ziemlich hoffnungsloses unterfangen werden.
Es ist guter Stiel Primary Keys und Foreign Keys zu definieren. Dadurch nutzt Du die Schutzmechanismen der Datenbank und erleichterst auch Deinen Kollegen die eventuell auch an der Datenbank arbeiten das Leben.
Eine Datenbank dessen Daten Inkonsistent geworden sind wieder sauber zu bekommen ist häufig ein schwieriges und undankbares unterfangen.
Das ist eine Sicherungsmaßnahme. PKs sind ja keinme Pflicht bei den mir bekannten Datenbanksystemen.
Nehmen wir an, du hast 5 verschiedene "Petra Müler" in deiner Datenbank. Eine davon heiratet nun und ändert ihren Nachnahmen.
Den Updatebefehl über den Namen einzuschränken bringt dir hier wenig, dann hättest du einen Update über 5 Zeilen. Deshalb hat jede Petra Müller eine ID Spalte, die als PK festgelegt ist. Somit kannst du genau die eine Petra Müller umbenennen, die auch wirklich umbenannt werden soll.
Man kann doch aber einfach sich selbst eine Spalte mit ID's erstellen, und diese verwalten, wozu also primary keys?
Wenn du aber nun (aus welchen Gründen auch immer) die ID 73654 doppelt einfügst, hast du nachher ein Problem.
Der PK verhindert hier den Insert.
Vielen Dank für die ausführliche Erläuterung! :-))))