[Erledigt] Freunde in Datenbank

Hallo,

ich möchte, dass meine User sich gegenseitig Freundeseinladungen schicken können.

Im Moment habe ich nur eine Tabelle (_user) in der die wichtigsten Infos sind.
ID || NAME || PASS
1 || User_1 || 123
2 ||User_2 ||321

Wie kann ich es am geschicktesten realisieren, dass sich die User untereinander befreunedn können?
Eine Tabelle (_freunde) und jede Freundschaftsanfrage einzelnt abspeichern?
ICH_ID || FREUND_ID
1 || 2

Allerdings müsste ich entweder immer 2 Datensätze abespeichern oder immer 2 Abfragen, weil User_1 mit User_2 befreundet ist aber auch User_2 mit User_1...

Dabei verhasbelle ich mich immer ...
Vielleicht kann ja jemand helfen?

Gruß

[Tholi]

Machst einfach eine weitere Tabelle wo du 2 Spalten hast. User 1 und User 2 und beide zusammen ergeben einen zusammen gesetzten Schlüssel. Und in einer dritten Spalte kannst noch 1 Flag setzen ob, die Einladung angenommen wurde oder nicht.

So würde ich das machen.

[JuniorChef]

Hmm wie soll das mit dem Schlüssel aussehen?
Bisschen mehr Details wären nicht schlecht =)
Gruß und Danke schonmal!!

[Tholi]

http://dev.mysql.com/doc/refman/5.1/...imary-key.html

Freunde
USER 1 | USER 2 |FLAG
abc | def | offen
.
.
.

[nikosch]

Bissel mehr wirds schon brauchen. Denn im Prinzip sagt die Tabelle nicht aus, wer jetzt wen eingeladen hat (und damit wer noch bestätigen muss).

[Tholi]

Nunja, man kann natürlich die beiden Userspalten so handhaben das die linke Spalte immer die rechte eine Einladung geschickt hat und das Flag drückt je nach Status aus, ob die Anfrage angenommen wurde, noch aussteht oder abgelehnt wurde. Und wenn die Ablehnungnachricht kommt, wird der Datensatz einfach aus der Tabelle geworfen.

[ChrisB]

Na ja, man kann ja bspw. den Anfrager immer als ersten, und den Angefragten als zweiten speichern ...

[nikosch]

Und wenn beide anfragen? Dann müsste an sich ja schon die Verbindung bestätigt sein, oder?

Und wenn, dann gibts doppelte Datenhaltung und bei jedem JOIN doppelte Datensätze.

[JuniorChef]

Danke für den Versuch... Ich versteh`s nicht....
Wo ist denn da der Schlüssel?! Bzw. was ist das: FOREIGN KEY(isbn) REFERENCES buecher(isbn) ON DELETE CASCADE ?

Gruß

[Tholi]

@nikosch: Kann man vorher doch prüfen ob eine Anfrage bereits vorliegt, bzw. ein solcher Datensatz existiert und dementsprechend eine Meldung ausgeben.

@JuniorChef: Schau dir SQL mal näher an, wenn du weiteres damit vor hast. Macht es nicht nur uns sonder viel mehr dir einfacher, bei Problemen helfen zu können.

[ChrisB]

Und wenn beide anfragen?

Absolut hundertprozentig gleichzeitig?
Wird nicht vorkommen. Spätestens die Verarbeitung der Anfragen wird seriell stattfinden.

Dann müsste an sich ja schon die Verbindung bestätigt sein, oder?

Na gut, also wenn A die Freundschaft von B angefragt hat, und dann B „gleichzeitig“ die Freundschaft von A anfragt - dann findet man in dem Moment, wo die Anfrage von B bearbeitet wird, schon die von A an B in der Datenbank. Das muss also nur noch erkannt und entsprechend drauf reagiert werden - nämlich, in dem man in dem Datensazt A|B|offen dann aus dem offen ein bestätigt macht.

[nikosch]

Spätestens bei „C ist Freund von A, weil B Freund von A und C von B eingeladen wurde“, funktioniert das aber nicht mehr.

[ChrisB]

War das irgendwo gefordert?

Ausserdem sehe ich da wenig Sinn drin - warum sollte B aussuchen (dürfen), wer As Freund ist?

Wenn A C befreunden wil, dann würde ich erwarten, dass A bei C anfragt.

[nikosch]

Wenn A C befreunden wil, dann würde ich erwarten, dass A bei C anfragt.

Keine Ahnung, wie das üblicherweise bei den gängigen Comunities läuft.

War das irgendwo gefordert?

Man darf auch mal einen Schritt weiterdenken.

[nikosch]

Und schon kommt das erste passende(re) Beispiel: http://www.php.de/datenbanken/67374-...tml#post511139