Datenbank Primary Key

[fkerber]

Der PK ist wie der Name sagt, ein Schlüssel - ein Schlüssel dient dazu, ein Tupel in einer Tabelle eindeutig zu identifizieren.

Dabei gibt es verschiedene Konzepte - ein Superschlüssel erfüllt einfach das o.g. - ein sog. Kandidatenschlüssel erfüllt das auch, ist aber zusätzlich minimal - d.h. man kann ihn nicht mehr kleiner machen, ohne, dass er nicht mehr Schlüssel wäre.

So, der primary key schlussenndlich ist ein an sich beliebig ausgewählter Kandidatenschlüssel. Besondere Bedeutung bekommt er, wenn es um Fremdschlüssel-zuweisungenn gibt...

Grüße, Frederic

[idefix2]

Als Primary key kannst Du eine beliebige Kombination von Feldern definieren, einzige Voraussetzung ist, dass diese Feldkombination jeden Datensatz eindeutig identifiziert. Zum Primary key legt das DBS automatisch einen Index an, der natürlich Unique ist. In der Praxis empfiehlt es sich UNBEDINGT, in JEDER Tabelle ein künstliches, Trigger-befülltes Feld zu definieren, das Du als Primary Key hernimmst. Jede andere Vorgangsweise führt mit ziemlicher Sicherheit früher oder später zu Problemen.

Zusätzlich zum Primary key, für den das DBS automatisch einen Unique Index anlegt, kannst Du nach beliebige andere Indexe (oder sagt man Indizes?) anlegen, die den Zugriff auf die Datenbank über die entsprechenden Feldelemente beschleunigen. Ist so ein Index als Unique definiert, dann erlaubt das Datenbanksystem keine 2 Datensätze mit identischen Feldwerten in diesen Feldern. Der Unique Index kann auch berechnet sein, so kannst Du einen Unique Index auf UPPER(Feld) legen und damit eine Case-insensitive Feldeindeutigkeit erzwingen.

Die Eindeutigkeit des Zugriffs an einen Index zu koppeln, ist insofern sinnvoll, als ohne vorhandenen Index die Überprüfung auf Eindeutigkeit extrem langsam wäre. Aber im Prinzip dient der Index in erster Linie zum schnellen Auffinden von Datensätzen und quasi nur als Nebeneffekt kann über einen UNIQUE Index Eindeutigkeit erzwungen werden.

Das Problem eines berechneten Unique Index ist, dass er nur vor dem Speichern von Duplicates schützt, beim Zugriff auf die Daten aber nicht verwendet wird. Wenn Du also irgendwo in einer Abfrage des Feldes auf =, <, >, like oder dergleichen abfragst, ist diese Abfrage erst wieder case-sensitiv und liefert Dir das gewünschte Ergebnis nur, wenn Du Upper(Feld) mit Upper(Vergleichswert) vergleichst.

Seit Firebird 2 ist es aber problemlos möglich, einem Feld eine caseinsensitive (und sogar eine accent insensitive) "Collation" zuzuordnen. Damit wird sozusagen das Feld selbst caseinsensitiv gemacht. Wenn Du das machst, wird automatisch überall, wo der Inhalt des Feldes mit etwas anderem verglichen wird, ein Case-insensitiver Vergleich durchgeführt. Es gibt standardmässig in Firebird zwar nur ganz wenige case-insensitive Collations, aber es ist sehr einfach, eine solche zu definieren - siehe http://www.delphipraxis.net/1031544-post57.html.

Die Verwendung von Uppercase-Schattenfeldern in der Datenbank war früher der einzig mögliche Workaround, weil es damals mit den Möglichkeiten der Datenbanksysteme nicht anders ging, hat aber heute bei einer Datenbankneuentwicklung überhaupt nichts verloren.