2012-03-23 9 views
5

Buduję społeczny wykres na mojej stronie. Użytkownicy będą tworzyć relacje (z formularza follower/follow), gdzie każda strona może samodzielnie podążać za drugą. Moja tabela użytkowników wygląda następująco:Modelowanie SQL Follower/Followed Relationships for Social Networking

Users table 
- UserId (PK, Auto-incrementing integer) 

Myśląc jak model ten, mam wymyślić kilka alternatyw, takich jak:

(a) Stół posiada każdy „” śledzić działania w postaci oddzielny wiersz.

Relationships table 
- FollowerId (FK to Users.UserId) 
- FollowedId (FK to Users.UserId) 

To ma tę wadę, że biorąc pod uwagę wielu użytkowników, tworzyłoby to ogromną liczbę rzędów.

(b) Tabela przechowuje listę użytkowników, każdy użytkownik jest następujący jako CSV lub innej struktury: (? I kosztowne)

Relationships table 
- FollowerId (FK to Users.UserId) 
- FollowingUsers (e.g. 2,488,28,40) 

Ma to tę wadę, że zapytania są znacznie bardziej skomplikowane. Chciałbym również, aby utrzymać kolejność z ciągów znaków, itp ...

(c) relacja na wiersz, w którym użytkownik może być po obu stronach „” relacji:

Relationships table 
- Party1Id (FK to Users.UserId) 
- FollowingParty2 (boolean) 
- Party2Id (FK to Users.UserId) 
- FollowingParty1 (boolean) 

Spowoduje to zapisanie wierszy (a), ale zapytania są bardziej złożone, ponieważ użytkownik może być jedną ze stron.

(d) Umieszczenie zarówno „po” i „a następnie” jako list, takich jak (b)

Relationships table 
- UserId (FK to Users.UserId) 
- FollowingUsers (e.g. 2,488,28,40) 
- FollowedBy (e.g. 2,488,28,40) 

To wydaje się najlepszy ze wszystkich światów, ale teraz muszę używać transakcji aktualizować wiele wierszy .

Zakładając, że zamierzam skalować do dużego rozmiaru, chociaż jestem świadomy, że "problemy Facebooka nie są moimi problemami" - która opcja lub która opcja jest preferowana?

Odpowiedz

5

pójdę z opcją A.

  1. Wszelkiego rodzaju analizy wykresu społecznego będzie możliwe przy użyciu innych opcji
  2. egzekwowania jakichkolwiek ograniczeń relacyjnych będzie możliwe przy użyciu innych opcji
  3. Nie ma to trzeba użyć relacyjnej bazy danych, jeśli nie planujesz przechowywania danych w sposób relacyjny.

Ciekawym rozwiązaniem może być rozważenie modelu relacji tabela: Tabela

Relacje

  • RelationshipId
  • UserId (FK do Users.UserId)
  • RelationType

Możesz teraz łączyć użytkowników.

przypadek B następuje:

  • dodać RelationshipId1, UserAId "IsFollowed"
  • dodać RelationshipId1, UserBId, "IsFollowing"

sprawa zaczyna Inny użytkownik następstwie:

  • dodać RelationshipId1, AnotherUserId, "IsFollowing"

przypadek Inny użytkownik uruchamia następujące B:

  • dodać RelationshipId2, AnotherUserId "IsFollowing"

Można nawet wyeliminować niepotrzebne wiersze, jeśli chcesz: A rozpoczyna się po B:

  • dodać RelationshipId3, UserAId, "IsFollowedAndIsFollowing"
  • dodaj RelationshipId3, UserBId, "IsFollowedAndIsFollowing"
  • usunąć RelationshipId1, UserBId, "IsFollowing"