Zastanawiam się, w jaki sposób zorganizować "znajomości" w serwisie, a ma to działać tak:

jeżeli zaprosiłem kogoś do znajomych to on musi to zaproszenie zaakceptować
i
jeżeli ktoś mnie zaprosił to muszę zaproszenie zaakceptować

w przeciwnym wypadku na liście znajomych nie pojawi się zaproszona do znajomych osoba.


Jak to optymalnie i możliwie prosto rozwiązać? Szukam tylko pomysłu

Tablica znajomi.

user1, user2, czy zaakceptowane

user1 zaprasza, user2 jest zapraszany, czy zaakceptowane domyślnie przybiera wartość nie.
Jeśli user2 nie przyjmie rekord jest kasowany, jeśli przyjmie czy zaakceptowane ma wartość tak.

Pojawiają się tylko osoby, które mają czy zaakceptowane tak.

Na przykład

Jeśli po zaakceptowaniu user1 jest znajomym usera2 i również user2 znajomym usera1, to wystarczy dodać rekord: user2, user1, tak

to chyba nie będzie zbyt optymalne rozwiązanie niestety. wyobraź sobie 100 000 użytkowników gdzie kazdy ma 50 znajomych - 5 000 000 rekordów w tabeli?

edit: a nie, przepraszam, 10 000 000 bo przecież trzeba dać dwa rekordy dla jednej znajomości wg. Ciebie

W efekcie końcowym musisz mieć tabelę, która posłuży za referencje między poszczególnymi osobami. Aplikacja obsługująca 100 000 osób posiada też duże zapotrzebowanie na pamięć - nie próbuj się przed tym bronić. Podczas zapraszania użyłbym jednak pośredniczącej tabli - np. zaproszenia, w której trzymane byłyby informacje: kto, kogo i na przykład kiedy. Pozostały już tylko odpowiednie reguły w kodzie i po zabawie.

W tym się pomyliłam, wystarczy zrobić przy wyświetlaniu prosty warunek or.

Jednakże chcesz zrealizować coś takiego, jak wiele do wiele, nie obejdziesz tego inaczej, bo taka jest specyfikacja tej transakcji. Prawda jest taka, że zależności są robione w podobny sposób i w wielkich serwisach, jeśli dodatkowo założysz indeksy na pola userów, to wszystko się przyspieszy.

Prawda jest taka, że można to zrobić inaczej. Możesz w tabeli użytkownicy zrobić pole znajomi i dopisywać tam kolejny numer znajomego i to czy zaproszenie już zostało przyjęte. Czyli wyglądałoby to na przykład tak:

21:t,42:n,14:t,5:t,62:t,523:t,53:n

wystarczyłoby to "zaledwie" n+1 razy potraktować explodem, lub czymś podobnym. Masz jedno pole, nie ileś milionów rekordów. Ale przeważnie się tak nie robi, bo jest to wolniejsze niż trzymanie wszystkiego w osobnych rekordach plus indeksy.

ale wezmy takie serwisy jak nasza klasa czy myspace. tam jest pare milionow userow i maja srednio po 200-300 znajomych. to jest kilka miliardow rekordow a jednak chodzi szybko(bez nk:D). jak to jest zrobione. tez sie na tym zastanawialem i nie doszedlem do tego

user_friends:
user_id|friend_id|status

nie ma problemów choć na razie mam tylko 40 tysięcy userów.

A czemu miałoby spowalniać działanie serwisu? Skrypt pobiera tylko potrzebne mu rekordy i dlatego właśnie trzeba strukturę bazy danych zaplanować jak najlepiej, ale na pewno nie według zasady, żeby zajmowało jak najmniej miejsca.

Szczerze nie wiem po co w ogóle tak nad tym rozmyślasz, bo nie sądzę żeby tworzony przez Ciebie serwis miał ani miliony użytkowników, ani w jakikolwiek sposób miał wolniej działać ze względu na złą ogranizację bazy danych.

A jeśli będziesz miał milion użytkowników, to dopiszesz do tego cachce i nie będzie obciążało bazy