Помогите с организацией выборки

Я трижды прочитал топик и не понял в чем собственно проблема заключается? Запрос не работает?

Проблема в том что вігребать таким образом весь рейтинг по городу, искать среди всех записей только 6, при чем для кадого юзера єти 6 будут разніми, очень не рационально..

И я никак не могу придумать, как оптимизировать весь механизм формирования рейтинга для каждого юзера

При изменении рейтинга страницы сразу записывать изменение в суммарный рейтинг пользователя в специальном поле в таблице с пользователями

не выйдет
Рейтинг формируется по критериям, сейчас пока по Городу.
Т.е у меня контентасоздано 3 для Киева, 2 - Москвы, 5- Львова.
И я увижу себя в 3х рейтингах..
Если у меня друг создавал для Петербурга контент, то просматривая рейтинги по Петербургу я там увижу друга, но не увижу себя

вариант с отдельной таблицей рейтинга как
parentuser , city , rating
тоже не пойдет?

Нет. так как город єто только первый критерий будут другие..
Да и что эта таблица упрощает?, то что во время выборки рейтинг уже просумирован..
Не знаю.. это вопрос к спецам, сильно ли sum() жрет ресурсов?

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

По поводу "жрёт ресурсов" лучше профайлера мускульного тебе никто не скажет. Если запрос реально тормозит, а не просто ловля блох, то я засунул бы просто в кеш и не парился. Если траблы с мемкешем, то воспользуйся мускулом с его memory table engine.

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

2RussianSpy - записей... Городов несколько десятков тысяч. но контента пока нету.. проэкт еще в продакшн не уехал...

memory table engine. ... надо почитать что оно такое

В кеш можно положить и на 10 мин )

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

напомню в результате нужно, ТОП3 юзера, мое место в рейте, место в рейте одного-трех моих друзей...

Сделай проще. Забей таблицу мусором, далее попробуй погонять просто запросом, посмотри на скорость. Если она реально не устраивает (а не просто хочется быстрее), то определись, на сколько должна быть актуальна информация (для кеширования). Если минут 5 - 10, то думаю кеш будет идеальным выходом (память нынче дешёвая).

Если до завтра не решится, то вечером ещё можно будет подумать - обсудить :)

Собственно ответ ввиде, "это не обьемы" меня тоже устаривает... я это еще не реализовал, просто не охото время на переделку потом тратить, его и так мало..

А при каких обьемах начнутся проблемы? Или так, тормозить не будет при одинароном запросе, а если их несколько штук одновременно?


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

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

Что скажите насчет такого запроса.
Точнее без гоняния профайлером омжно ли что-то сказать, насколько он оптимален:

[highlight="sql"]
SELECT @pos as posit, rt.firstname, rt.cuid, rt.rating, rt.fuid FROM
(SELECT @pos:=0) p,
(SELECT u.firstname as firstname, c.uid as cuid, f.uid as fuid, c.city, sum(c.rate) as rating
FROM content c
LEFT JOIN user_profile u ON c.uid=u.id
LEFT JOIN friends f ON f.aid=c.uid
WHERE ( c.city=1 )
GROUP BY c.uid
ORDER BY rating DESC) rt
WHERE ( (@pos:=@pos+1)<4 OR rt.fuid=7 OR rt.cuid=7 )
[/highlight]

т.е. я выбираб весь рейтинг: имя, рейтинг, идшник юзера, потом из этих результатов выбираю только себя, друзей и запустив итератор который дает мне номер строки(читай позицию в рейтинге) в фильтр добавляю только первые три

Итого что я этим получил
1. Мне не нужно вытягивать в скрипт весь рейтинг
2. Потом перебором сравнивать нужные идшники юзеров
3. Существенно усложнился запрос

Вот теперь интересно стоит ли шкурка вычинки...

Лично я бы все таки рейтинг не пересчитывал каждый раз, а хранил расчитанным и изменял бы при каждом действии пользователя. Поставил Вася оценку Пете плюс стопицот - изменилась оценка Петиной статьи, тут же в спец таблицу (userid, rating) сделан запрос rating+100500 where userid равно Пете. И таким образом всегда будет одна таблица полностью содержащая сумму всех оценок каждого пользователя. И таких таблиц можно сделать много привязываясь к разным параметрам статистики.

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

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

Как говорят мастера дзеня - "Преждевременная оптимизация - корень всех зол" или из 37Signals: "Пока проблема не возникла, её просто не существует" ) Нужно реально смотреть на сколько допустима нагрузка на машину.