Datenbank Primary Key

[JoltinJoe]

Hm und welche Funktion hat dann der PK ? Also klar "die Daten sind dann leichter abrufbar" aber kann da jemand genauer drauf eingehen ? Hat das was mit der "Binären Suche" zu tun ?

Und zum Problem: Also es gibt keine Möglichkeit einem Feld die Eigenschaft CASE INSENSITIVE zu verschaffen ?

[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.

[shmia]

Zitat:

Zitat von JoltinJoe (Beitrag 1031742)

Hm und welche Funktion hat dann der PK

Ohne PK sind die Daten in einer Tabelle quasi "verloren".
Stell' Dir vor, du hast eine Tabelle in der einige Datensätze völlig gleich sind:

Code:

FeldA | Feld B | Feld C
=======================
430   | 14.70  | blau
590   | 20.00  | rot
430   | 14.70  | blau

Dich stört der doppelte Datensatz; du willst ihn löschen.
Mit SQL gibt es aber keine Chance nur einen der beiden Datensätze zu löschen.
Das gleiche Problem entsteht beim Editieren.
Über eine UPDATE-Anweisung würden immer beide Datensätze geändert.
Nur wenn eine Tabelle einen PK hat, kann garantiert werden, dass jeder Datensatz einzeln ansprechbar ist.

[DeddyH]

Außerdem kommt der PK noch bei Detailtabellen zum Tragen. Hier muss der Master-Datensatz ja eindeutig identifizierbar sein.

[idefix2]

Der Primary key ist aber nichts anderes als ein willkürlich ausgewählter eindeutiger Schlüssel. Wenn Du die Datensätze über unterschiedliche Schlüssel eindeutig identifizieren kannst, dann kannst Du theoretisch jede beliebige Kombination von Feldern, die die Datensätze eindeutig identifizieren, zum primary key ernennen. Früher hab ich das gelegentlioch so gehandhabt, es ist mir aber noch jedesmal später auf den Kopf gefallen. Deshalb die Empfehlung, als Primary Key prinzipiell ein künstliches Feld zu verwenden, das mit Hilfe eines insert-Triggers und eines Generators (neuerdings heisst das auch in Firebird - SQL Standard gemäss - Sequence) gesetzt wird.

[DeddyH]

Das hat ja auch niemand bestritten. Ich persönlich verzichte allerdings gelegentlich auf einen Generator, wenn es sich um eine Auflösungstabelle einer m:n-Beziehung handelt. In dem Fall kann man IMO auch getrost die Kombination der beiden FKs als PK definieren. Wobei es natürlich auch nicht schadet, auch hier einen künstlichen Schlüsel zu erzeugen und die angesprochene Kombination einfach UNIQUE zu deklarieren. Wie man sieht gibt es hier mehrere Möglichkeiten.

[idefix2]

Ja, Du hast schon Recht. Wenn es sich nur um eine Auflösungstabelle einer m:n-Beziehung handelt, könnte man sich das künstliche Feld samt Trigger wahrscheinlich sparen.

[mkinzler]

Er schadet aber nicht und ermöglicht eine spätere Erweiterung

[JoltinJoe]

Hm okay eine Sache ist noch unklar.

Wenn ich ein Feld_A habe und dieses als PK definieren will dann soll ich ein künstliches K_Feld_A erzeugen und einen Trigger auf das eigentliche Feld_A setzen. Danach kann ich K_Feld_A als PK definieren.

Und was soll das ganze ? Warum definiert man nicht gleich das Feld_A als PK ?