Господа, представьте, что пред нами стоит задача реализовать сервис, в котором будет иметься сущность "Пользователь". Одной из функций сервиса является список друзей. Как на ВКонтакте.

Самым простым решением представилось создать таблицу users {id, name} и таблицу friendsships {user_id, friend_id}. Естественно, что friendships - это ассоциация. Однако, если призадуматься, у этого подхода есть недостаток, когда речь идет о связи сущности в пределах одной таблицы.
Недостаток заключается в следующем - идеологически, если мы сопоставим пользователю с id = 1 пользователя с id = 2, то выглядеть это будет так:

friendships
1 | 2 

Вроде нормально, на первый взгляд, однако, если призадуматься, то можно заметить, что с точки зрения той же самой идеологии у первого пользователя есть друг - это второй пользователь, а вот у второго пользователя первый другом не является. Да, согласен (пока), что можно выполнить обратный Select, который по friend_id будет выбирать user_id, которые, учитывая особенность этого подхода, то же являются такими же полноправными друзьями, но - это уже как-то не изящно, что ли, выполнять такую операцию в два запроса...Тем более это перегружает мой API, пусть и не сильно, конечно, но тем не менее это решение как-то не шибко мне нравится. Разве что можно написать 1 запрос, который будет совмещать в себе выборку как из первого столбика, так и из второго, но что-то не получается у меня написать этот запрос без вложенных подзапросов. Если можете написать такой - буду благодарен!

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

friendships
1 | 2
2 | 1

Теперь все вполне нормально селектиться одним запросом, НО! Опять же - решение не совсем в стиле реляционной схемы, насколько мне кажется... Да и запрос на добавление, редактирование и удаление, отныне, будет двойной. То же не есть гуд...(((

Вопросы:

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

Заранее благодарю.
Тема мне очень интересна, был бы рад привлечь как можно больше дискуссирующих.

Достаточно сделать union двух запросов.



Какой вариант применять, зависит от того, будет ли граф друзей направленным или нет. Т.е. ты добавил человека в друзья, а он тебя нет.

Вы не определили свойства связи полностью. 

Если из того, что 2 есть друг 1 однозначно проистекает что 1 есть друг 2 - используется подход 1. Если нет - подход 2.

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


Akina, вы уверены, что не перепутали местами подходы?

Тогда делай первый вариант.

Уверен. Более того - убежден.

Хорошо, в таком случае ещё один вопрос:

Для того, чтобы выбрать всех друзей конкретного пользователя, я использую следующий запрос:



Рационален ли он с точки зрения производительности и не сильно ли грузит базу данных?

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