nicht angemeldet
yo,
primary keys sind so definiert, dass sie immer zwei eigenschaften (contraints) besitzen müssen. erstens sind sie nicht leer (not null) und sie sind in der entsprechenden tabelle eindeutig (unique). fehlt einer der beiden eigenschaften, dann kann es keine pk sein. unique alleine reicht also nicht aus. soviel zu der definitin eines primary keys.
in der praxis kommt es nun vor, dass eventuell mehrere einzelne spalten, bzw. auch zusammengesetzte spalten diese beiden eigenschaften besitzen. in deinem falle könnte somit sender + empfaenger einen solchen zusammengesetzten pk bilden, wenn du ihnen die oben genannten BEIDEN eigenschaften zuteilst.
zusätzlich kommt noch hinzu, dass es sich in der praxis bewährt hat, keine spalten als pk zu verwenden, die ein attribut (eigenschaft) der jeweiligen tabelle darstellen, sondern künstliche schlüssel zu verwenden, die also nur dazu dienen, jeden datensatz in der tabelle eindeutig zu identifzieren, aber keine weiteren informationen "tragen". der grund dafür liegt darin, dass man den inhalt des pk nicht ändern sollte, sprich der wert bleibt "lebenslang" erhalten. bei sogenannten sprechenden schlüsseln (pk deren wert eine bedeutung hat) besteht immer die gefahr, dass sie sich im laufe des datenbank-lebens doch mal ändert. ein beispiel für einen sprechenden pk wäre zum beispiel das autokennzeichen in einer tabelle auto (internationale autoschilder mal ausgenommen).
so haben wir in unserem derzeitigen projekt in jeder tabelle nur künstliche schlüssel, die aus einzelnen spalten bestehen und deren spaltenname immer mit _pk endet. es ist letzlich eine philosophie und meiner meinung nach auch erfahrungssache, welche spalte man nun zu einem pk macht.
und um endlich auf deine frage zurück zu kommen.
Das Problem ist: Es gibt keine Wert der Einmalig ist. Aber dafür ist die Kombination aus sender-empfaenger einmalig was man ja am UNIQUE KEY erkennen kann.
hier kannst du eine künstliche schlüsselspalte einfügen, die den pk der tabelle darstellt. dann bist du auf jeden fall auf der sicheren seite. es ist aber auch durchaus legitim, die beiden spalten sender und empfanger zusammen als pk zu verwenden, wobei du ihnen dann beide eigenschaften not null und unique zuordnen musst. ich vermute mal, bei den beiden spalten handelt es sich sowieso um fremdschlüsseln zu einer anderen tabelle ?
Ilja