Как лучше организовать структуру БД, для организации модуля друзей на сайте?

Question

[SharkyFLY]

Есть сайт с MySQL базой. Пишу модуль (раздел) «друзья». Функции как всегда: добавление, удаление, подтверждение, отклонение заявки. Как лучше организовать структуру, чтобы уменьшить нагрузку?

Answer 1

[SwampRunner]

ваш id, friend_id друга

1 2
2 1

если есть пара, то вы друзья, если нет, тоесть только 1 2 или 2 1, то ещё нет ждёте подтверждения.

Вот такой запрос, выдаёт список друзей:

SELECT login, friends.id AS check_id, friends.friend_id AS check_friend_id,
(SELECT id FROM friends WHERE id=check_friend_id AND friend_id=check_id)AS checkout
FROM friends LEFT JOIN users ON (users.id=friends.friend_id)
WHERE friends.id=?i
HAVING checkout IS NOT NULL ORDER BY login

И два индекса на id, friend_id и наоборот friend_id, id

Есть вариант второй, делать только одну запись, но добавить поле friendship, а потом проверять её наличие и если есть, то апдейтить friendship=1. Надеюсь вам это поможет.

Comments

[Макс Кузнецов]

Имхо, второй вариант самый правильный. К тому же этот способ позволяет узнать, кто кого пригласил и принято ли приглашение (поля friend_from_id, friend_to_id, accept).

Answer 2

[Gibbzy]

many — to — many relationship
советую ознакомится с такими вещами и типами связанности таблиц
и еще нормализация, да если вдруг не знаете такого.

Answer 3

[IlVin]

Сделайте табличку дружественных связей uid2uid и очередь (другая табличка или сторонний модуль) на внесение изменений в табличку связей. Главное, чтобы в очередь заявок сами заявки инсертились «со свистом» (INSERT DELAYED)…

Answer 4

[skvot]

Еще вариант — таблица с полями id1, id2, status. id1 — тот, кто предлагает дружбу, id2 — кому предлагают, status — состояние связи. Частично проигрывает вариантам, перечисленным выше, но жизнь у такого тоже есть. Например, если Вам нужно больше типов связей — кроме друга еще, например, родители и т.д.

Comments

[skvot]

Сори, выше этот способ уже описан.

Answer 5

[Jazzist]

Добавить таблицу «Друзья» с внешними ключами и статусами.

Оптимальным решением будет использовать нессиметричную структуру данных, вроде такой:
uid — пользователь, которому принадлежит запись
friend — пользователь-друг
status — одно или несколько полей статусов. Если будете использовать несколько полей с булевыми флагами — решение получится менее ресурсоемким, то есть более производительным.

Просмотр списка друзей пользователя — выборка из списка по ключу uid.

Все другие функции сводятся к установке/изменению статусов записей в этой таблице.

Answer 6

[Vitold S]

Почему-то подумал, что можно повесить на Redis в множество. Быстро считать сколько друзей позволит. Правда не знаю как делать выборки по друзьям из базы )))

Answer 7

[Vitold S]

Не специалист в этом вопросе, но что лучше делать подзапрос как предложили

SELECT login, friends.id AS check_id, friends.friend_id AS check_friend_id,
(SELECT id FROM friends WHERE id=check_friend_id AND friend_id=check_id)AS checkout
FROM friends LEFT JOIN users ON (users.id=friends.friend_id)
WHERE friends.id=?i
HAVING checkout IS NOT NULL ORDER BY login

ИЛи же сделать:

SELECT id,friend_id FROM subscription s1
INNER JOIN subscription s2 WHERE s1.uid = s2.fuid and s1.fuid = s2.uid;

что в принципе даст пересечение на себе?!

Тут вопрос производительности )))