Problem: Buddy-Liste

Problem: Buddy-Liste

Das hat jetzt nichts mit den Übungsaufgaben zu tun:
Wie setzt man eine Buddylist bzw. Freundesliste in vernünftiger Form um? 1:n oder n:m Beziehungen wie die folgende sind ja kein Problem:

USER
userID
name

INTERESTS
interestID
interest

USER_TO_INTERESTS
userID
interestID


Aber wie setzt man eine Freudesliste um? Das Problem ist in diesem Falle, dass man eine n:m Beziehung zu sich selbst hat. Eine Tabelle

BUDDYLIST
userID1
userID2

entspricht keiner Normalform. Außerdem würde alles doppelt gespeichert (wenn a mit b befreundet ist, dann muss auch ein Eintrag b mit a rein). Alternativ müssten doppelte Abfragen her (gibt es einen Eintrag "a mit b" oder "b mit a"?).

Habt ihr eine Idee, wie man so etwas vernünftig umsetzen kann?

Interessante Frage
Aber ist das nicht eher ein semantisches Problem?

Ansatz 1:
Ich verwende die Informationen dahingehend, dass ich für jeden Benutzer seine Freunde zugeordnet wissen will.

BUDDYLIST
userID
friendID

Klar ist eine Information hier ansich (ggf.) redundant, aber bedient den Ansatz perfekt. Die Redundanz ist jedoch keine Verletzung der Normalform, da ja bewusst gespeichert wird, welche Freunde ein Benutzer hat, nicht welche Freundschaftsbeziehungen existieren. Hier lassen sich auch Situationen realisieren, in denen Benutzer1 Benutzer2 als Freund markiert, Benutzer2 jedoch Benutzer1 nicht als Freund.

Ansatz 2:
Ich möchte eine Liste aller Freundesbeziehungen halten.

BUDDYLIST
userID1
userID2

Das entspricht Deinem Entwurf und sollte natürlich keine Redundanz beinhalten, denn hier passt sie vom Ansatz her nicht hinein.

Ich würde einen der Ansätze wählen und dann ggf. mittels einer View den anderen bedienen. Besser ist m.E. der, der den Verwendungsgedanken besser widerspiegelt.

Das mit der nicht gegenseitigen Freundschaft ist genau mein Problem. Aber du hast Recht, das ist ein semantisches Problem und alle Varianten, die ich mir hier so auf dem Schimerzettel niedergeschrieben habe, sind noch weitaus schlimmer

Freundesbeziehungen laufen letzten Endes auf die gleiche Tabelle hinaus, da jede "Freundschaft" eine eigene ID bräuchte und in einer weiteren Tabelle dann userID,freundschaftID gespeichert werden müsste. Da kann man auch gleich userID1 und userID2 (friendID) nehmen.

Außerdem ließe sich eine Freundschaft nach erstem Ansatz wunderbar benutzen, um die Freundschaft zu bewerten. Es gibt ja Freunde und es gibt "Freunde"... Und das wiederum kann man statistisch auswerten, wie sehr die gegenseitigen Ansichten einer Freundschaft doch auseinanderliegen, hehe.