Мне нужно мнение эксперта MySQL для создания системы друзей

Question

Мне нужна помощь в разработке системы друзей

Таблица MySQL:
список друзей
- auto_ id
- Friend_ ID
- user_ id
- утвержден_ статус

Вариант 1 = Каждый раз, когда пользователь добавляет пользователя, в БД добавляется 2 записи, мы можем найти там таких друзей, как этот

SELECT user_id FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'

---

Вариант 2 = Мы добавляем 1 запись для каждого добавленного друга, а затем получаем список друзей, подобный этому

SELECT friend_id AS FriendId FROM `friends_list` WHERE user_id='$userId' and approved_status='yes'
UNION
SELECT user_id as FriendId FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'

Из 2 приведенных выше способов иметь друзей на таком сайте, как myspace, facebook, на всех других сайтах, какой из 2 приведенных выше методов будет наилучшим?

1-й метод удваивает количество строк, например, сайт с 2 миллионами строк-друзей будет только на 1 миллион строк вторым методом.

Тем не менее, метод объединения означает, что было сделано 2 запроса, поэтому 2 запроса к таблице с миллионами строк вместо 1?

---

UPDATE

Я только что провел тест на 60 000 друзей, и вот результаты, и да, таблицы проиндексированы.

Вариант 1 с 2 записями на друга;
.0007 секунд

Вариант 2 с 1 записью на друга с помощью UNION для выбора
3100 секунд

Answer 1

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

Answer 2

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

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

В настоящее время я сам создаю эту функцию, и было бы интересно узнать о вашем опыте в этом вопросе.

Answer 3

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

Кроме того, вам необходимо учесть будущую гибкость, которую может использовать otehr для данных.

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

Answer 4

Если вы индексируете user_id и friend_id, то эти два оператора должны быть эквивалентны по времени - лучше всего это проверить - базы данных могут иметь удивительные результаты. UNION рассматривается базой данных, и он может использовать его для оптимизации запроса.

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