Attribute zu einem Primärschlüssel zusammenfassen

deetee

Hallo,

ich habe heute voller Erstaunen gelernt, dass man z.B. 2 Felder zu einem Primärschlüssel zusammenfassen kann.

Mir erschließt sich allerdings nicht genau, warum man das tun sollte, da meines Erachtens die Übersicht darunter leidet. Es macht die Sache wesentlich komplexer und unnötig komplizierter.

Wär super, wenn mir jemand ein nettes Beispiel nennen könnte, damit ich das auch verstehe.

mortino

Der Primary Key bestimmt die Eindeutigkeit der Datensätze in einer Tabelle.
Stell dir eine Tabelle vor in welcher Benutzer (UID) Prozessen (PID) zugeordnet werden sollen.
Jeder User darf mehrere Prozesse haben, genauso kann ein Prozess mehreren Benutzern zugewiesen sein.

Würde man den PK nun nur über ein Feld wählen, dann wäre die obige Angabe nicht erfüllbar, da entweder jeder Benutzer oder jeder Prozess nur genau einen Eintrag haben könnte.

Wählt man den PK jedoch über beide Spalten im Vebund, kann die gewünschte Anforderung erfüllt werden.

Reicht das oder soll ich da mal ein konkretes Beispiel aufschreiben?

deetee

hm, versteh ich nicht so ganz. Würde man das nicht eher mit Fremdschlüssel lösen?

Allgemein kann man es doch eigentlich immer umgehen, das man keine 2 Felder als PK zusammenfassen muss, indem man eben als PK ein normales ID Feld definiert.

Aber ein konkretes Beispiel wäre super.

SideWinder

Das mit der id ist wahr - allerdings wird nicht immer eine id benötigt. Meistens eben bei Tabellen die eine :-Beziehung auflösen (wie das obrige Beispiel).

Zur Verdeutlichung:

Tabelle: Prozess
pid number PRIMARY KEY,
pname varchar2(100)

Tabelle: User
uid number PRIMARY KEY,
uname varchar2(100)

Tabelle: Prozesse_User
pid number,
uid number
PRIMARY KEY(pid, uid)

Natürlich könnte man in der Verbindungstabelle Prozesse_User eine Spalte puid einführen - diese hat allerdings keinen Zweck (da reiner Speicherverbrauch). Somit ist es viel einfacher pid&uid als Primary Key zu definieren.

BTW: Nein, FOREIGN KEYs werden benötigt um zwei Tabellen zu verbinden die in einer 1:*-Beziehung stehen.

MfG SideWinder

deetee

hallo,

ok das macht Sinn, danke.

deetee

Hallo,

also nochmal eine Frage dazu:

Warum nimmt man nicht einen Unique Index, statt einem PK in der Tabelle Prozesse_User?

Würde beides gehen oder macht ein PK mehr Sinn?

mortino

Ein PK ist einzigartig für jede Tabelle und stellt die Eindeutigkeit eines Datensatzes in dieser Tabelle sicher.
Indizes werden in der Regel verwendet um zusätzlich eine optimierte Suche auf bestimmte Spaltenkombinationen in einer Tabelle zu bieten. Der Unique Index stellt zudem noch die Eindeutigkeit der Spaltenkombination dar, ist aber egtl nicht dafür vorgesehen die Eindeutigkeit eines Datensatzes festzulegen.
Man könnte das zwar so verwenden, es wär aber nicht sauber gelöst.

Zudem ist es auch an und für sich so, dass Foreign Keys nur über PKs angelegt werden können (wobei ich denke, dass dies sehr vom jeweiligen System abhängt). Somit könnten bei Verwendung eines Unique Index die Vorzüge von FKs entfallen.

Ausserdem darf man auch nicht vernachlässigen, dass ein Unique Index unter Umständen im jeweiligen RDBMS anders implementiert ist als ein Primary Key. Während PKs oftmals direkt als Regel einer Tabelle angelegt sind, werden Unique Indizes über zusätzliche Objekte in der Datenbank dargestellt.

Das unterscheidet sich natürlich von System zu System.

Viel wenn und aber. Es bleibt aber eindeutig, dass zu jeder Tabelle ein PK gehört, ein Unique Index jedoch nur optional ist.

Ach ja: Ein PK stellt im übrigen auch sicher, dass keine NULL Werte eingefügt werden.

deetee

Der FK Wegfall bei Unique Index ist im Grunde der einzige echte Nachteil...wenn man denn einen FK benötigt. Braucht man ihn nicht, würde also auch ein Unique Index ausreichen.

Ich meine nämlich nicht, dass jede Tabelle unbedingt einen PK benötigt. Vielmehr denke ich, dass es gerade auch deswegen den Unique Index gibt, als abgespeckte "Version" des PK, z.B. möchte man zwischen Tabellen die referentielle Integrität sicherstellen, braucht man PKs, ist dies nicht von Nöten, dann reichen Unique Indizes.

Deshalb denke ich, es ist eher eine Sache des speziellen Anwendungsfalls, statt des verwendeten Systems.

Nein. Jede Tabelle muss einen PK haben! Ich habe schon erlebt, dass das Fehlen eines PK Probleme bereiten kann (insbesondert Inserts und Updates können dadurch richtig ins Schleudern geraten).
Wie mortino schon gesagt hat, ist das natürlich vom DBMS abhängig. Ich würde da allerdings kein Risiko eingehen.

mortino

@deetee: Nicht unbedingt. Man kann sich sicher sein, dass ein PK immer die optimale Lösung bietet die Eindeutigkeit auf einer Tabelle darzustellen.
Ein Unique Index dagegen ist abhängig von der Implementierung dessen im jeweiligen RDBMS maximal so gut optimiert wie ein PK.
Wie gesagt, einige System legen für einen Unique Index zum Beispiel ein zusätzlich Objekt zur Verwaltung desselben an. Das wird niemals effizienter sein als die Implementierung des PKs. Im besten Fall ist die Einbindung die gleiche und somit beides auch gleich effizient.

Fairer Weise muss ich natürlich zugeben, dass die Unterschiede zwischen den beiden marginal sein dürften. Aber wieso nicht von vorneherein die 'bessere' Lösung wählen? Bzw. ein Unique Index hat ja auch dennoch seine Berechtigung, aber ausgehend von dem Fall seh ich da keinen Grund nicht den PK zu verwenden.

Also ich würde egtl immer den PK vorziehen und wüsste jetzt auch aus dem Stegreif keinen Fall bei dem ein Unique besser wäre.
Wenn du da mal ein konkretes Beispiel hast, gern her damit. Ich lass mir da gern auch was anderes zeigen.