Уважаемые эксперты/программисты базы данных:
У меня есть таблица 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.
Мой вопрос в том, что эта конструкция базы данных корректна для этой проблемы (учитывая избыточность и оптимизацию базы данных)? Или может быть лучший подход, чем это? Спасибо.
В целом, ваш дизайн правильный.
Но если user_id уникален в таблице "пользователи", вам не нужен столбец "id" в "users". (Отдельная таблица, содержащая уникальный "id" и уникальный "user_id", довольно необычна.) Вам также не нужен столбец "id" в таблице "followers".
Первичный ключ в "последователях" должен быть (user_id, follower_id) и убедиться, что каждый из этих столбцов имеет внешний ключ, ссылающийся на "user_id" в "users".
Общий совет. Используйте целые числа для идентификаторов, а не строк. Существует значительная разница в производительности. Поэтому отпустите users.user_id и переименуйте users.id в users.user_id. Во-вторых, таблица ваших подписчиков должна иметь индексы для user_id и follower_id. Снова появляется значительное преимущество в производительности. Мне также нравится идея иметь уникальный индекс на (user_id, follower_id), вызывающий этот первичный ключ и удаление столбца id.
Да, ваш дизайн - это обычный способ общения с отношениями "многие ко многим". Найдите "моделирование базы данных" многие-ко-многим ", и вы найдете много ресурсов, дающих вам примеры этого.
Добавьте внешние ключи из таблицы отношений в таблицу users.
Если ваши отношения связаны с дополнительной информацией, вы должны поместить это как столбец в свою таблицу соединений. Может быть, например, дата, когда один пользователь начал следовать за другим.
Отдельный суррогатный ключ в соединительной таблице, такой как добавленный вами столбец идентификатора, может быть полезен, если вы захотите, чтобы другие таблицы ссылались на вашу таблицу.
Вот мой дизайн.
Id userId(PK) followerId followedDate unfollewedDate
1 123 456 YYYY-MM-DD HH:MI:SS YYYY-MM-DD HH:MI:SS
... ... ... ... ...
Я предположил, что userId - последовательное объединение является уникальным. Даты могут быть полезны. Например, я собираюсь использовать, если пользователь отменит подписку и последует за 5 минут, это не приведет к уведомлению. Я предполагаю, что пользователь сделал это по ошибке. И я могу проанализировать статистику по дате.