Последователь моделирования SQL / отслеживаемые отношения для социальных сетей

Question

Я строю социальный график для своего сайта.Пользователи будут создавать отношения (формы подписчик / подписчик), где каждая сторона может независимо следовать за другой.Моя таблица пользователей выглядит следующим образом:

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

Думая о том, как смоделировать это, я придумал несколько альтернатив, таких как:

(a) Таблица содержит каждую подписку'действие в виде отдельной строки.

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

Это имеет тот недостаток, что, учитывая множество пользователей, он создает огромное количество строк.

(b) Таблица содержит список пользователей.каждый пользователь следует в виде CSV или другой структуры:

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

Недостатком является то, что запросы будут намного сложнее (и дороже?).Я также должен был бы поддерживать порядок строковых значений и т. Д. ...

(c) Отношение в строке, где пользователь может находиться на любой "стороне" отношения:

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

Это сохраняет строки над (a), но запросы являются более сложными, потому что пользователь может быть любой из сторон.

(d) Помещение обоих «следующих» и «сопровождаемых» как списков, подобных (b)

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

Это кажется лучшим из всех миров, но теперь я должен использовать транзакции для обновления нескольких строк.

Предполагается, что я хочу масштабировать до большого размера, хотя знаю, что«Проблемы Facebook - это не мои проблемы» - какой вариант или какой другой вариант предпочтительнее?

Answer 1

Я бы выбрал вариант А.

1. Любой вид анализа социальных графов будет невозможен при использовании других опций
2. Реализация любых видов реляционных ограничений будет невозможна при использовании других параметров
3. Нет необходимости использовать реляционную базу данных, если вы не планируете хранить данные реляционным способом.

Одним из интересных вариантов может быть рассмотрение модели таблицы отношений:

Таблица отношений

• RelationshipId
• UserId (от FK до Users.UserId)
• RelationType

Теперь вы можете подключать пользователей.

случай B следует за A:

• добавить RelationshipId1, UserAId, "IsFollowed"
• добавить RelationshipId1, UserBId, "IsFollowing"

case Другой пользователь подписался на A:

• добавить RelationshipId1, AnotherUserId, "IsFollowing"

case Другой пользователь начинает подписываться B:

• добавить RelationshipId2, AnotherUserId, "IsFollowing"

Вы можете даже удалить ненужные строки, если хотите: A начинает следовать за B:

• добавить RelationshipId3, UserAId, "IsFollowedAndIsFollowing"
• добавить RelationshipId3, UserBId, "IsFollowedAndIsFollowing"
• удалить RelationshipId1, UserBId, "IsFollowing"