алгоритм

Всем доброго времени суток.

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

у меня практическая аналогичная задача, есть таблица в базе со всеми "друзьями"
есть несколько вариантов как сделать эту казалось бы простую проверку

1) (самый ресурсоёмкий) каждый раз находить всех друзей в базе и если такого id нет то писать "добавить в друзья" иначе же это друг и выводить "отправить сообщение"
сами понимаете, если допустим всего в сети 1000 человек то перекрёстно это очень много запросов

2) изначально к каждому профилю привязывать файл(текстовый) и хранить там его друзей и получаем как минимум в 10 раз больше приемущества (я так думаю, чем меньше запросов тем лучше)

3) хранить в таблице самого профиля массив со всеми твоими друзьями (в принципе тоже не совсем накладно)

4) использовать кэширование, запрос со всеми твоими друзьями из базы вытащил и в кэш(оперативку сервера засунул)

Помогите пожалуйста, может у кого свой вариант есть, а то в голову не приходит что лучше, (учитывается то что ресурс будет высоко-средне нагруженным)

-----
Самое лучшее решение проблемы
самое простое

0) Сделать таблицу user_friends, в которой хранить пары friend_0_id, friend_1_id - являющиеся ссылками на таблицу users. Тогда запрос потребуется ровно один.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

какие проблеммы с запросом к таблице по индексному полю ?

(Отредактировано автором: 26 Апреля, 2013 - 18:38:30)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

EuGen, я немного не догнал можно немного поподробнее?

у меня есть таблица friends_iv всех друзей id id_user id_user_friend
если я не ошибаюсь то вы тоже самое имели ввиду?!

(Отредактировано автором: 26 Апреля, 2013 - 18:55:49)

-----
Самое лучшее решение проблемы
самое простое

Есть таблица, в ней хранятся связи. В таблице есть индекс по каждой колонке и по двум колонкам (всего три). Запрос на поиск, есть ли в списке друзей указанный пользователь, будет использовать индексацию и потому будет выполняться быстро.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Есть табличка пользователя, в котором есть поле friends.
В этой табличке хранить id каждого друга, тоесть идентификатор-логин.
Выбираем одним запросом массив данных этого поля, сверяем в цикле
каждый id с id-ом к кому зашли на страницу, если id совпали:
Выводим - "Отправить сообщение"
если нет:
Выводим - "Добавить в друзья"

Логика простая.

Medallion по таблице на каждого юзера???
это как же потом с такой бд работать?
страшно представить этот список в инструменте

я смотрю о соединении таблиц "многие-ко-многим" никто не слышал
(Добавление)

если не учитывать что логики никакой нет вообще

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

скорее всего там каждый юзер сидел со своими данными в своей песочнице. Но даже в этом случае это не слишком оправдывает.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

esterio если значительно большим станет количество таблиц, то в проблему превратится поиск нужной таблицы
и поиск не индексированный заметь
бред со всех сторон

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

ты уверен что не о вертикальном разделении сейчас говоришь?

в общем на чем они аииграли
1. данние разделены а значит и join- ить ничего не нужно на равне с union
2. префиксы таблиц легко подставить в запрос при правильном проектировании
3. диапазон виборки сужается из за того что нету данных чужого пользака
4. лок проходит только на таблицу пользака. а ето означакт что другие юзеры успешно пользуются своими данными
(Добавление)
LIME
да уверен. база одна и сервер также. никаких репликаций как они заверяли
(Добавление)
но ето скорее исключительнпя ситуация. для повишения производительности все таки лучше использовать кластеры, репликацию, кеширование и прочую лабуду. да и редко проект состоит из полностю разделяемых данных где связи не нужны.

1. не очень понимаю каким боком тут join ?
если разделение юзеров не означает что вообще отсутствуют реляционные отношения и все данные юзера тупо сваливаются в одну таблицу

2 id юзера для индексного поля еще проще

3. для отбора опять же по индексному ключу несущественно

4. не знаю в каком году это писалось и для какой БД (может для DBF ?) но нынешняя mysql вроде как блокирует на уровне страницы а не на уровне таблицы.

да и вообще сейчас кагбэ партицирование поддерживается и все такое.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore