дизайн базы данных для «подписчиков» и «подписчиков»?

Question

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

У меня есть таблица 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. Это то что мне нужно.

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

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

Answer 1

в общем, ваш дизайн правильно.

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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