Хранение друзей в базе данных для социальной сети

Question

Для хранения отношений друзей в социальных сетях, лучше иметь другую таблицу со столбцами relationship_id, user1_id, user2_id, time_created, pending или если user_id подтвержденного друга будет выделен в одну длинную строку и сохранен вместе с другими данными пользователя, такими как user_id, name, dateofbirth, address и не более 5000 лайков, похожих на фейсбук?

Есть ли лучшие методы?Первый способ создаст огромную таблицу!Во втором столбце есть одна очень длинная строка ...

На странице профиля каждого пользователя необходимо извлечь всех его друзей из базы данных, чтобы показать, как 30 друзей похожи на Facebook, так что я думаю, что первыйметод использования отдельной таблицы вызовет огромное количество запросов к базе данных?

Answer 1

Самый правильный способ сделать это - иметь таблицу членов (очевидно) и вторую таблицу отношений друзей.

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

Если предположить, что таблица Member выглядит следующим образом:

MemberID int Primary Key
Name varchar(100) Not null
--etc

Тогда ваша таблица дружбы должна выглядеть так:

Member1ID int Foreign Key -> Member.MemberID
Member2ID int Foreign Key -> Member.MemberID
Created datetime Not Null
--etc

Затем вы можете объединить столы, чтобы составить список друзей

SELECT m.*
FROM Member m
RIGHT JOIN Friendship f ON f.Member2ID = m.MemberID
WHERE f.MemberID = @MemberID

(Это именно синтаксис SQL Server, но я думаю, что он довольно близок к MySQL. @MemberID - это параметр)

Это всегда будет быстрее, чем разделение строки и выполнение 30 дополнительных SQL-запросов для извлечения соответствующих данных.

Answer 2

Отдельная таблица как в методе 1. метод 2 плох, потому что вам придется каждый раз десериализовать его, и вы не сможете выполнить JOINS для него; плюс ОБНОВЛЕНИЕ будет кошмаром, если пользователь меняет свое имя, адрес электронной почты или другие свойства.

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