n:m Beziehung in beide Richtungen

Hallo,

ich stehe gerade vor dem Problem der Abspeicherung von Daten. Und zwar geht es darum, dass Personen mit anderen Personen befreundet sind. Dies ist eine n:m Beziehung und wird in einer weiteren Tabelle ausgelagert.
Tabelle Person schaut ca. so aus:
CREATE TABLE person(
id integer PRIMARY KEY,
name varchar(40) NOT NULL,
...
);
Tabelle Freundschaft schaut ca so aus:
CREATE TABLE freundschaft(
f1id integer references person(id),
f2id integer references person(id),
status integer NOT NULL,
PRIMARY KEY (f1id, f2id)
);

Wenn Person1 nun mit Person2 befreundet ist, so gilt die Freundschaft natürlich auch andersherum.
Ist es nun sinnvoll die die datn doppelt abzuspeichern oder sollte man lieber bei allen selects mit union arbeiten?
Bei Änderungen der Freundschaft müsste man natürlich auch immer auf beide werte überprüfen.

Also würdet ihr doppelt abspeichern und die datensätze doppelt verwalten oder lieber einmal abspeichern, dafür dann aber komplizierte statements?

Als Beispiel für einfache Speicherung:
wenn die Freundschaft |1|2|0| besteht und jemand versucht |2|1|0| zu speichern, gibt das keine Duplicate Key Exception, so müsste man vorher überprüfen ob die die Beziehung mit vertauschten Werten bereits exisistiert.

Vielen Dank!

 

Andererseits muss man bei doppelten Datensätzen immer beide Informationen identisch halten, was auch einen gewissen Aufwand bedeutet. Wenn dein Frontend das hergibt, würde ich die einfache Datenhaltung bevorzugen und alles andere mit Abfragen machen. Ich weiss aber aus eigener Erfahrung, das manche (Fremd-)Anwendungen damit überfordert sind...

 

Die Persistenz-Schicht wird sowieso von mir geschrieben. Das heißt, um die wirkliche Datenhaltung muss sich die Service-Schicht nicht kümmern.
Derzeit hab ich es sowieso nur einmal abgespeichert, ich dachte nur, dass es vielleicht eine andere bessere Möglichkei gibt. Das einzige was mir noch einfallen würde, wäre einen Trigger auf die Tabelle zu setzen der das überprüft, das ist dann aber leider in der Persistenz-Schicht nicht mehr so ersichtlich, warum es dann Fehler gibt.

PS: Danke für die schnelle Antwort. Geht ja echt flink hier.

 

Die "normale" Arbeit kann langweilig sein

Mit einem Trigger kannst du zumindest bei MSSQL einen Fehler provozieren, vermutlich mit der gleichen Fehlerkennung wie eine PRIMARY KEY Einschränkung. Ein Trigger als Duplicate Key Exception wäre sicher nicht die schlechteste Wahl. Ob es noch andere Einschränkungsmöglichkeiten für das Problem gibt, weiss ich allerdings nicht.