Klausurfrage

Nonens

Nonens

Lounge-Member
Vielleicht wurde diese Frage irgendwann mal gestellt, dann bitte ich um Verzeihung, wenn ich sie jetzt noch mal stelle, ich habe die Suchfunktion nicht bemüht, weil ich nach der Google-Suche zwar Antworten gefunden habe, aber nicht ausreichend, also nicht so, dass ich es verstanden hätte:

Kann mir jemand den genauen Unterschied erklären, was so an einem Unique Key anders ist als an einem Primary Key?
Ich weiß, dass ein Unique Key (UK) die Eigenschaften eines Primary Keys hat, ich weiß, dass der Primary Key (PK) die Zeilen identifizieren soll und der UK die Eindeutigkeit garantiert.

Aber für mich stellt sich die Frage: dann könnte doch ein UK die Aufgaben des PK übernehmen? Wozu dann überhaupt noch ein PK? Oder umgekehrt? Das verstehe ich nicht ...

Kann mir das jemand erklären?
 
Eine Tabelle kann mehrere UKs haben, aber nur einen PK.
Ein PK muß zwingend ein UK sein, i.d.R. nimmt man dazu den kürzest möglichen UK (kurz im Sinne von minimal nötiger Spaltenanzahl). Der Grund dafür ist, daß der PK in Tabelle 1 bei einer Verknüpfung zum FK in Tabelle 2 wird und da sollte man nicht unnötig viele Daten hin und herschaufeln müssen. Meist ist es sinnvoll einen PK bestehend aus nur einer Spalte zu besitzen (i.d.R. ein Integer).

Wenn man einen UK Index auf einer Spalte oder Spaltenkombination anlegt, fordert man von der Anwendung, daß sie immer eindeutige Werte in der Tabelle ablegt, sonst *Peng*. Außerdem kann die DB so eine bessere Suchfunktion aufbauen, d.h. ein UK Index _kann_ schneller und platzsparender abgelegt werden, als ein normaler Index mit der Möglichkeit von doppelten Einträgen (das kann sich aber auch erst bei sehr großen Datenmengen bemerkbar machen).

Eine Tabelle kann durchaus auch ohne PK auskommen; ohne UK wirds meist schwer, d.h. kommt i.d.R. eigentlich auch nicht vor. Meist ergibt sich ein UK auch von selbst. Allerdings wird er oft nicht unbedingt als Index angelegt, da ist er auf jeden Fall, auch wenn vom "DB-Designer" unbemerkt.
Ein Beispiel für eine Tabelle die ohne PK auskommt wäre eine Zuordnungstabelle bei der Auflösung einer n:m Beziehung. Die beiden FKs aus den jeweiligen Tabellen sind zusammen der UK, ein PK wird im Grunde nicht benötigt. (bin mir aber nicht sicher, ob es die großen DBs zulassen eine Tabelle ohne PK zu erstellen, sollte aber gehen). Wobei logisch gesehen ist der UK hier auch der PK, selbst wenn er im Schema nicht explizit so benannt wird.

Ob ein UK die Aufgabe des PKs übernehmen kann? Ja könnte er, aber der Sinn von einem PK ist es eine einzige zentrale Referenz in / zu dieser Tabelle zu haben, über die alle anderen Tabellen angeschlossen werden. Wenn Du plötzlich zwischen den Keys wechselst, dann hast Du nachher ein ziemliches Durcheinander (schließlich muß irgendjemand noch die Anwendung dazu stricken und die will bestimmt nicht mit vielen verschiedenen Schlüsseln arbeiten müssen).
Außerdem könnte die Existenz mehrerer kurzer oder relativ kurzer (im Verhältnis zu Gesamtspaltenzahl) UKs auf ein Datenbankdesign hinweisen, daß nicht ordentlich normalisiert ist.
 
Albu hat das ganze oben optimal erklärt, ich wollte jedoch nur noch etwas zum Thema Performance hinzufügen:
Wie Albu bereits erwähnt hat, werden Schlüssel in einem Index gespeichert, was eine Beschleunigung zur Folge haben kann. Der MySQL Standard-Index-Typ beispielsweise ist extrem schnell bei Abfragen, die eine individuelle Zeile oder einen Zeilenbereich suchen. Jedoch auch bei Joins zwischen Tabellen, Datengruppieren, Datensortierungen sowie bei Suchen nach Maximal- bzw. Minimalwerten. Beim Abrufen aller Tabellenzeilen bzw. normalen Abfragen, wirken sich die Indizes nicht positiv auf die Geschwinidkeit aus.

Eine Suche nach einem Schlüssel kann i.d.R. schon nach kurzer Zeit zurückgeliefert werden, ist kein Index vorhanden, muss erst die gesamte Tabelle durchsucht werden und jedes mal mit der Abfrage verglichen werden, was klarerweise viel langsamer von statten geht.
Deshalb sollten auch Daten, nach denen sehr häufig gesucht wird, als Schlüssel definiert werden. Jedenfalls sollten auch nicht zuviele Schlüssel vergeben werden, denn Indezes verbrauchen nunmal Speicherplatz und es ist jedesmal eine Aktualisierung der Indezes notwendig, wenn eine Zeile hinzugefügt, gelöscht oder ein Suchattribut geändert wird, was Aktualisierungsoperationen verlangsamt - also gut durchdacht einsetzen ;)

Eine Abfrage wird auch nicht beschleunigt, wenn beispielsweise eine Suche oder-verknüpft wird, wenn einer der beiden Werte keinen Index aufweist.

Teilweise kann man auch die Länge der Indezes verkürzen indem man beispielsweise nicht ein ganzes Wort, sondern nur ein paar Buchstaben indizieren lässt. Ein kleinerer Index führt natürlich auch zu schnelleren Abfrageoperationen.
 
zu den Indizes nochmal eine kleine Ergänzung:
Wenn man alle Zeilen der DB abruft, dann muß das nicht unbedingt langsam sein, vorausgesetzt, man setzt keine WHERE oder ORDER ein, die aus nicht indizierten Feldern besteht. Soll heißen ein "select * from tabelle;" ist sicherlich schneller, als ein "select * from tabelle order by feld1;", wenn feld1 kein Indexfeld darstellt. Wenn es ein Index ist, dann ist es minimal langsamer als das nackte Select. Der Grund: zuerst wird die Index Tabelle ausgelesen und sortiert, um dann auf die Hauptdaten zuzugreifen. Da Indextabellen i.d.R. relativ klein und performant sind ist das aber meist vernachlässigbar. Ein order by feld1 ohne Index bedeutet, daß die komplette Original-Tabelle durchsucht werden muß, um danach eine sortierte Ausgabe zu erzeugen.

Wenn ein Feld Teil eines zuammengesetzten Index ist, dann sollten die Abfragen auch in der Reihenfolge der Indexzusammenstellung erfolgen. Wenn feld1 z.B. in index1 an Position 2 vorkommt, dann wäre obiges Select wie eines ohne Index zu behandeln. Befindet es sich an Position 1, so funktioniert es wie bei einem eigenen Index (so ist es z.B. in mysql umgesetzt andere Datenbanken mögen dies anders umsetzen, darauf verlassen würde ich mich darauf allerdings nicht).

Wenn die Datenbank die komplette Tabelle (sei es die eigentliche Datentabelle oder die Indextabelle) komplett durchforsten muß, dann nennt man das auch "Table Scan". Meist versucht man solche Table Scans zu vermeiden, in bestimmten Fällen lassen sie sich nicht vermeiden (wenn man alle Datensätze nach Datum sortiert braucht, dann braucht man sie eben).

Die meisten Datenbanken bieten die Möglichkeit seine Abfragen anhand eines Profilers zu optimieren. Dabei kann man eine oder mehrere Abfrage durch den Parser und Interpreter jagen und er spuckt die dabei vorgenommenen Optimierungen und Entscheidung zusammen mit einer Statistik aus. So kann man sehen, ob die DB die eingerichteten Indizes auch verwendet.
 
Beifall, meine Herren!

Sauberer hätte man das ganze wohl nicht erklären können. Ich selber hätte mich da wohl etwas schwerer getan, obwohl ich um die Zusammenhänge weiß.

Das zeigt mal wieder welches Fachwissen sich hier im Forum ballt :)

Weiter so.
 
@Albu:
Habs mir gestern in der Nacht noch am PocketPC durchgelesen, weiß nicht mehr genau was du geschrieben hast, aber ich erinnere mich daran, dass du einen Teil von mir eingebaut hast und das weiter ins Detail geschrieben hast.
Werde mir das am Nachmittag nochmal durchlesen, denn alles entspricht glaube ich nicht ganz der Wahrheit... :p
Hab jetzt aber keine Zeit dafür - aber schön langsam sollten wir überlegen, ob wir nicht ein Buch schreiben :D
Aber ich denke mal, Nonens Frage ist ausreichend beantwortet :D:D
 
@rk: schade, daß Dir meine Ausführungen nicht zusagen..

Als Disclaimer sollte ich vielleicht dazu sagen, daß ich die Infos lediglich mal so ausm Kopf weg runtergeschrieben habe. Wenn es Details gibt, die nicht korrekt sind, dann raus damit!
 
Albu schrieb:
@rk: schade, daß Dir meine Ausführungen nicht zusagen..
Zum Vergrößern anklicken....
Doch doch Albu! Deine Ausführungen gefallen mir sogar sehr gut ;)
Ist auch alles in Ordnung, habe glaube ich im halb schlafenden Zustand nicht mehr ganz folgen können was du überhaupt gemeint hast, deshalb hab ich es nun nochmals durchgelesen, jetzt konnte ich dir auch folgen und kann nur zustimmen... :)

Ein Kapitel haben wir ja nun schon fast fertig. Womit machen wir weiter ;)
 
Danke an alle, die geantwortet haben!!! :) So ausführlich hätte ich es nicht gewußt, aber dieser Grundgedanke kam mir dann auch, als ich mit meiner Klassenkameradin darüber diskutierte. Bin nur froh, dass wir richtig lagen! Danke noch mal für die Mühe, das so ausführlich und toll zu erklären!!!

Klausur habe ich heute geschrieben, das kam zwar nicht dran, aber die Arbeit habe ich wohl trotzdem in den Sand gesetzt.

Naja, spielt jetzt auch keine Rolle mehr ;)

Danke noch mal!!!!

Gruß,
Nonens
 
Ja, ja, mach Dich nur lustig über mich! :p

Dafür habe ich in meiner c++ Klausur eine 2-, und das war auch noch die zweitbeste Arbeit! *allabätsch* ;)
 
Ejal, ich hab in C 'ne 1 gehabt und in Shell 'ne 5. Irgendwie werd ich mit Unix nicht warm, aber ich hab ja noch zwei Anläufe.
 
Naja, die 2- hab ich auch nur geschafft, weil wir Klassendiagramme, Sequenzdiagramme und Zustandsdiagramme können mußten. Hätten wir irgendwas Programmieren müssen, hätte ich verloren ... :D
 
in der letzten klausur mußten wir ein sortierprogramm auf papier schreiben und noch andere kleinigkeiten ...
 
Jo ich auch, einen sortierten ausgeglichenen Binärbaum - eingefahren...
[EDIT]für euch: in den Sand gesetzt ;)[/EDIT]
 
Zuletzt bearbeitet:
Klar mach mal Doublehashing unf Heapsort auf Papier! Letztens war's ein Münzwechsler, oder strcat().

Da wirscht nimmer Herre.
 
Naja, so schwierig war's nicht. War Bubblesort, lineare Suche und noch zwei. Schon wieder vergessen. :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben