Дизайн базы данных для "последователей" и "последующих"?

Уважаемые эксперты/программисты базы данных:

У меня есть таблица mysql с информацией о пользователях, например

id      user_id         name etc.
1       userA            
2       userB   
3       userC
..      ..
..      ..

Я хочу создать такую функцию, как "следовать" другим пользователям, например, твиттер. Пользователь A может следовать за пользователем B, или пользователь может следовать за пользователем A, или оба могут следовать друг за другом. Для этого нужно создать 1 таблицу, скажем, последователей

id      user_id     follower_id
1           userA       userB
2           userC       userA
3           userA       userC
4           userB       userC
5           userX       userA

Теперь я хочу найти, кто следит за пользователем. Я бы так хотел: Выберите * от подписчиков, где user_id = userA Это выберет userB и userC. То, что мне нужно.

Теперь я хочу найти, какие люди userA следуют (например, в таблице выше, userA соответствует userC и userX. Тогда мне нужно запустить что-то вроде Выберите * от подписчиков, где follower_id = userA.

Мой вопрос в том, что эта конструкция базы данных корректна для этой проблемы (учитывая избыточность и оптимизацию базы данных)? Или может быть лучший подход, чем это? Спасибо.

Ответ 1

В целом, ваш дизайн правильный.

Но если user_id уникален в таблице "пользователи", вам не нужен столбец "id" в "users". (Отдельная таблица, содержащая уникальный "id" и уникальный "user_id", довольно необычна.) Вам также не нужен столбец "id" в таблице "followers".

Первичный ключ в "последователях" должен быть (user_id, follower_id) и убедиться, что каждый из этих столбцов имеет внешний ключ, ссылающийся на "user_id" в "users".

Ответ 2

Общий совет. Используйте целые числа для идентификаторов, а не строк. Существует значительная разница в производительности. Поэтому отпустите users.user_id и переименуйте users.id в users.user_id. Во-вторых, таблица ваших подписчиков должна иметь индексы для user_id и follower_id. Снова появляется значительное преимущество в производительности. Мне также нравится идея иметь уникальный индекс на (user_id, follower_id), вызывающий этот первичный ключ и удаление столбца id.

Ответ 3

Да, ваш дизайн - это обычный способ общения с отношениями "многие ко многим". Найдите "моделирование базы данных" многие-ко-многим ", и вы найдете много ресурсов, дающих вам примеры этого.

Добавьте внешние ключи из таблицы отношений в таблицу users.

Если ваши отношения связаны с дополнительной информацией, вы должны поместить это как столбец в свою таблицу соединений. Может быть, например, дата, когда один пользователь начал следовать за другим.

Отдельный суррогатный ключ в соединительной таблице, такой как добавленный вами столбец идентификатора, может быть полезен, если вы захотите, чтобы другие таблицы ссылались на вашу таблицу.

Ответ 4

Вот мой дизайн.

Id    userId(PK)  followerId     followedDate         unfollewedDate
1     123         456            YYYY-MM-DD HH:MI:SS  YYYY-MM-DD HH:MI:SS
...   ...         ...            ...                  ...

Я предположил, что userId - последовательное объединение является уникальным. Даты могут быть полезны. Например, я собираюсь использовать, если пользователь отменит подписку и последует за 5 минут, это не приведет к уведомлению. Я предполагаю, что пользователь сделал это по ошибке. И я могу проанализировать статистику по дате.