nicht angemeldet
yo,
ich muss nochmal auf deinen ersten beitrag hier eingehen.
<zitat> Der eindeutige Schlüssel, der gefunden werden soll, besteht aus den drei Teilen A-B-Z </zittat>
ich denke, wir reden über diesen primär-schlüssel. und solange besucher und veranstallter sich nicht mehrmals treffen wollen, solange braucht man nur A/B als zusammengestzten schlüssel, sprich Z ist hier überflüssig. auch macht es meiner meinung nach sinn, die buchungen von den aussteller von den buchungen der besucher in zwei tabellen zu trennen. aber das ist sicherlich geschmackssache.
ein Unique-feld muss nicht zwangsweise auch bestandteil eines schlüssels sein,
Jedes Feld, das in einen Index aufgenommen wird, ist auch Bestandteil eines Schlüssels, nämlich des des Index. Über den Index (auch Schlüssel genannt) kann man die Datensätze auffinden. Wenn dieser Index primär ist, identifiziert er auch den Datensatz.
ein index ist sicherlich ein schlüssel, aber ich sagte ein Unique-feld, vielmehr ein Unique constraint ist nicht zwangsweise auch bestandteil eines schlüssel. ich habe mich bei mysql schon mal darauf aufgehangen, weil mysql --> immer <-- einen index zu einem Unique contraint anlegen will. dass ist aber mysql spezifisch und ziemlich dumm. ein Unique constraint ist nämlich kein index, sondern benutzt diesen nur, um den contraint zum beispiel bei 1 millionen datensätze schneller ausführen zu können. aber es würde auch ohne einen index gehen, oder wie oracle es macht, erst einmal nachschauen, ob ich nicht schon einen index auf die entsprechende spalte habe. sollte dies nämlich der fall sein, so brauche ich nicht noch zusätzlich einen anlegen. ist ja auch irgendwie albern, zwei indexe auf eine und dieselbe spalte zu haben. und genau das versucht mysql und wenn ich mich nicht ganz täusche und der name des vorhandenen indexes der gleiche ist, den mysql durch den unique contraint anlegen will, dann gibt es eine fehlermeldung (nicht ganz sicher).
Dies hier ist übrigens ein gutes Beispiel dafür, dass ein Unique Key nicht auch gleichzeitig ein (gültiger) Primärschlüssel sein muss
hat auch keiner behauptet. allerdings ist es meiner meinung nach etwas verwässert von einen unique key zu reden. sicherlich löst mysql das so, ich würde aber von einem unique constraint reden.
Der Unterschied zwischen den beiden (Unique Key und Primary Key) ist die Bindung an die Daten. Ein Primary Key hat eine unbedingte _Bindung_ an den Datensatz, ist aber niemals selber Bestandteil der Daten des Datensatzes. Unsere drei Schlüssel hier sind aber Bestandteil der Daten.
natürliche schlüssel sind sicherlich auch bestandteil der daten, obwohl ich selbst solche schlüssel nicht verwenden würde. aber es gibt trotzdem noch einen weiteren unterscheid, zwischen Unique und primary key. die unique spalte wird auch NULL werte mit aufnehmen, der PK würde das nicht tun.
grundsätzlich gilt für einen PK, er muss den datensatz eindeutig identifizieren, sprich er besitzt zwei contraints, NOT NULL und UNIQUE. so und nicht anders ist meiner meinung nach ein PK definiert. und dabei ist von index erst einmal keine rede, auch wenn es sinn macht, immer automatisch durch das dbms einen anzulegen.
Ilja