Angenommen, alle Ihre Freunde befinden sich auch in der Benutzertabelle, benötigen Sie eine Freundestabelle, die eine einfache Eins-zu-Viele-Beziehung definiert und die Benutzertabelle mit sich selbst verknüpft. Also
User Table
UserID int identity not null
[other attribute fields]
Friends Table
UserIDLink1 int
UserIDLink2 int
[other attribute field]
Wobei sowohl UserIDLink1 als auch UserIDLink2 Fremdschlüssel in der Users-Tabelle sind.
Also zum Beispiel, wenn ich drei Benutzer habe
1 Joe
2 Bill
3 Jane
und Joe und Jane sind Freunde, dann würde die Friends-Tabelle eine einzelne Zeile enthalten
1 3
Das Obige geht implizit davon aus, dass, wenn A ein Freund von B ist, B ein Freund von A ist - wenn dies nicht der Fall ist, möchten Sie wahrscheinlich UserIDLink1 und UserIDLink2 in UserID und FriendID oder ähnliches umbenennen - in diesem Fall würden Sie haben auch bis zu doppelt so viele Rekorde.
Auch für die bidirektionale Konfiguration (A ist ein Freund von B, wenn B ein Freund von A ist) sollten Sie Indizes in der Friends-Tabelle für (UserIDLink1,UserIDLink2) und (UserIDLink2,UserIDLink1) einrichten, um sicherzustellen, dass der Zugriff immer effizient ist, wenn Wir haben entweder nach Freunden von Joe oder Freunden von Jane gesucht (wenn Sie den zweiten Index nicht eingerichtet haben, wäre die erste Abfrage eine effiziente Indexsuche, aber die zweite würde einen vollständigen Tabellenscan erfordern).
Wenn Ihre Links nicht bidirektional wären, wäre dies nicht notwendig, um herauszufinden, wer die Freunde von A sind, aber Sie würden es wahrscheinlich trotzdem am dringendsten benötigen, da Sie wahrscheinlich auch herausfinden müssen, wem B ein Freund ist.
