Рачей пишет:Ну вообщем да.. Ни будут дружить друг с другом. Мы их заставим)
Такого, практически, не будет. Но не суть.
Не надо выдумывать проблему в виде абстрактного коня в вакууме, и пытаться её как-то решить.
Во-вторых: в таблицу связей добавляете два составных уникальных индекса - (user_id1, user_id2) и (user_id2, user_id1).
Второй ключ необходим для обратного поиска по user_id2 (друзья друзей),
так как при поиске сравнение осуществляется от крайнего левого индекса.
Т.е. user_id1 == 21 и друзья (user_id2) 22,23,24.
Индексы будут построены на основе сбалансированных деревьев - B-tree.
B-tree (он же binary tree индекс) - это индекс, сгруппированный по листьям бинарного дерева.
Применяется для больших индексов. По сути - это индекс индексов.
Например, индексы с величиной от 1 до 10 хранятся в одной ветке, от 11 до 20 в другой и т.д..
Когда приходит запрос на индекс с номером 21, то смещается ко 2-й ветке и находит там 1-й элемент. Нажмите для увеличения
Ну и, соответственно, тоже самое для составных индексов.
Для user_id 21 будут отфильтрованы:
2122
2123
2124
...
Отфильтруются не более userСount записей,
т.к. фильтр по одной только ветке: user_id(21) -> [.......]
Ну, и к тому же, - они уникальны.
А чтобы не подсчитывать количество друзей каждый раз при необходимости,
добавьте в таблицу пользователей поле count_friends и прибавляйте/убавляйте на единицу для обоих пользователей
при добавлении/удалении друга одного из них.
Можно соответствующие триггеры повесить для обновления данного поля.
К тому же, значение этого поля можно будет использовать для указания limit'а при выборки друзей,
для которой, в свою очередь, можно создать вьюху (VIEW) vew_friends для удобства, чтобы просто:
Мелочь, тем не менее ... )
Так что, пусть они там хоть все друг с другом "зафрэндятся".
К тому же (уверен), Вам захочется получить, например, список общих друзей.
В любом случае, - проблемы решаются по мере их поступления.
Да и вертикальное масштабирование никто не отменял.
Как бы там не было оптимально, для любого, хоть самого оптимального, решения может настать момент, когда тупо не хватает ресурсов.
Или Вы думаете, известные мега-проекты так и работают на самом дорогом серверочке,
который только смог позволить себе "тот студент" в начале своего стартапа ?
А чтобы не возникали вопросы а-ля "как правильно сделать?" - больше читайте.
В данном случаю порекомендую книжку "MySQL[dot] Оптимизация производительности".
(Добавление)
Мелкий пишет:Может, у кого другого ещё желание надавать по пальцам?
Да пора карму уже вводить с возможностью минусовать (только для админов), чтобы тупо понижали карму за подобный бред и не тратили нервы.(Отредактировано автором: 30 Июля, 2016 - 10:53:12)
|
Главная
Помощь
Поиск
Пользователи
Без описания
)
