Как сделать топ пользователей?

Question

[Just OK]

Здравствуйте.
Есть таблица, в которой содержаться строки id, amount, и user_id
Как на SQL(можно с PHP) можно сделать топ пользователей по сумме содержащейся в amount.
Я понимаю, что нужно суммировать amount для каждого пользователя, но как данную тему реализовать не могу понять.

Answer 1

[FanatPHP]

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

select user_id, sum(amount) total from table group by user_id order by order by total desc limit 20

Comments

[Just OK]

Благодарю, подошло)

[FanatPHP]

Ты хотя бы для приличия спросил, что тут для чего.
Чтобы не "дядя с с тостера сказал", а хотя бы немного понимать, как это работает.

[xmoonlight]

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

[Just OK]

FanatPHP, Я понял, что к чему) Просто я не мог вдуплить, как это все реализовать)

Answer 2

[xmoonlight]

Вообще, правильно считать единый amount для каждого юзера (и изменять его при создании/удалении записи и т.д.).
А не суммировать и сортировать из тучи строк - это крайне трудоёмкая операция для БД.

Comments

[Just OK]

Ну так уже не выйдет, как можно еще реализовать?
Может как-нибудь с помощью PHP?

[xmoonlight]

Just OK, почему не выйдет?
Создайте триггеры в БД и столбец для нужного показателя в таблице пользователей. По триггеру - прибавляйте или отнимайте нужное число в этом столбце.
А вывод - просто по этому столбцу сортировка и всё.
(это всё делается в БД, кроме самого вывода)

[FanatPHP]

Насчет правильности чья бы корова мычала.
А твоя бы почитала про нормализацию БД

[Just OK]

xmoonlight, Да просто дело в том, что уже есть забитые данные в таблицу.

[xmoonlight]

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

LIMIT сильно снижает нагрузку когда строк мало - здесь не спорю, но если строк несколько миллионов - этого даже не видно.

Поэтому, я знаю о чём говорю.

[xmoonlight]

FanatPHP, Давай честно: ты не работал с крупными порталами.

[xmoonlight]

Just OK, Рано или поздно - всё равно придётся переделывать, если строк с amount будет больше.
Т.к. чем больше строк, тем медленнее будет происходить обработка выборки в БД.
Если количество строк будет постоянным - то всё ОК.

[xmoonlight]

Bavashi,

У тебя amount динамический, каждый раз при его изменении тебе надо делать сортировку по всем значениям

зачем?! У меня есть сводная таблица: userID и чего-то там amount. Я выбрал по ID-шнику юзера (объекта) и поправил поле.
Именно в этом вся соль ускорения при работе со статой: аналитика/представление.

[xmoonlight]

Bavashi, почему?
Как я понял задачу: есть туча строк, которые необходимо просуммировать прежде, чем получить конечный суммарный ammount по КАЖДОМУ юзеру и после - отсортировать.

А мой вариант - уже всегда хранит этот суммарный ammount по каждому юзеру в таблице.
Просто сортируем по этому полю и выводим.

[xmoonlight]

Bavashi, меняю значение в сводной таблице для этого юзера.

[xmoonlight]

Bavashi,

Один юзер изменил свой amount - ваши действия?

зачем сортировку? (мы ничего тут не выводим)

[xmoonlight]

Bavashi, блин, ты специально опять или настолько непонимаешь?!
Ещё раз: Мне не нужно собирать amount для конкретного юзера из нескольких строк через выборку. Это значение - хранится всегда в одной ячейке с привязкой к юзеру по ID.
Я пропускаю шаг подсчёта суммы с выборкой при каждом выводе.
Теперь, понятно?

[xmoonlight]

Bavashi, Надо сравнить:
1. Как часто происходит изменение значения для конкретного юзера (один юзер - один пул).
2. Как часто нужен агреггированный вывод.
Явно, что вывод - гораздо чаще нужен, чем изменение значения для КОНКРЕТНОГО! юзера.

[xmoonlight]

Bavashi,

Оно динамическое и ты его будешь вынужден менять, а потом сортировать столбец.

Меняю - ТОЛЬКО! при изменении значения.
Сортирую - ТОЛЬКО! при выводе среди всех (или TOP N) юзеров.

[xmoonlight]

Bavashi,

Ну и домыслы.

Аргументируй.

Ты просто сам запутался в своем решении изобретая ненужные костыли.

Так все говорят, когда не понимают ничего.

[xmoonlight]

Bavashi,

В чем отличие агрегатного решения? Все никак не поймешь, что сортировку ты не минуешь?

Затратная операция - не сортировка, а выборка из тучи строк нужных для подсчёта конечной суммы! Это я миную при изменении и при выводе.

[xmoonlight]

Bavashi,

Это ты аргументируй, с чего ты взял, что вывод чаще, причем "Явно".

Потому, что статистика юзеров - у всех выводится несколько раз в секунду при запросах.
А изменение для УНИКАЛЬНОГО AMOUNT - делается только при совершении конкретного действия конкретным юзером для конкретного объекта. Это точно реже, чем вывод.

[xmoonlight]

Bavashi,

Ты ее не минуешь - ты ее подменяешь пулом запросов к БД от юзеров, меняющих свой амаунт.

откуда там пул? там просто запросы на UPDATE для конкретного ID и всё. Притом, они все могут исполняться асинхронно.

[xmoonlight]

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

[xmoonlight]

Bavashi,

В данной ситуации, прежде чем ты эти агрегированные данные подготовишь, ты нагрузишь БД сильнее, чем один агрегатный запрос.

ЧАВО?! ЗАПРОС - точно ОДИН?! )))
Для любого AMOUNT и для каждого юзера - он будет как из пулемёта!

Учись думать и разбираться, прежде чем сравнивать.

Я стараюсь, чего и тебе желаю.

[xmoonlight]

Bavashi,

Для твоего понимания, почитай про update, которому прежде, чем изменить значение нужно его еще найти и только потом изменить

По ключу - не нужно искать: это ссылка.

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

Домыслы. Т.к. всё зависит от конкретной логики сервиса для изменения значения. Это могут быть и НЕ юзеры. В любом случае - юзеры прибавляются медленнее, чем строки в "простыне" с изменениями туда-сюда и потом их агрегация.

[xmoonlight]

Bavashi,

Один итоговый запрос vs пул запросов от всех юзеров, когда ты готовишь, как ты же пишешь, агрегированные данные. Не понял?

Нет итогового ОДНОГО! ИХ столько, сколько запросов на агрегацию данных!
А это - ПОСТОЯННО УВЕЛИЧИВАЮЩАЯСЯ НАГРУЗКА на БД!.

Желай только себе, rkjey.

:D

[xmoonlight]

Bavashi,

Никакой выгоды.

Только в твоём понимании.

P.S. Неудивительно было читать про тебя столько отрицательных отзывов читать. Устройся на работу что ли.

Спасибо, что так переживаешь. Вижу, что ты работу себе нашёл по своему уму)))

[xmoonlight]

Bavashi, То, что мне искать не придётся ничего среди тучи строк. Вот и вся сложность.
А это - сильно увеличивает скорость работы (получения ответа от) БД.

[xmoonlight]

Bavashi, Твоя стата: Карма: read-only 39 дней Ты - ВООБЩЕ НИКТО!
Bavashi - Это DUMMY! Тупишка!)
Публикаций у тебя сколько?! Точно не 0?!)))

[xmoonlight]

Bavashi,

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

Каких (кроме UPDATE в момент изменения)?

[xmoonlight]

Bavashi,

update будут лететь от всех юзеров + сама сортировка, которую тоже придется делать неизбежно.

Про update:
1. Выполняется только на конкретный результирующий amount
2. Выполняется асинхронно
3. Возможно исполнение через стековое накопление

Сортировка - только по результирующим полям amount (по количеству юзеров).

Она будет чуть дешевле, но вместе с апдейтами преимущество нивелируется. Это же понятно.

Это полное непонимание процесса работы с БД. Мне даже пояснять здесь уже нечего...

[xmoonlight]

Bavashi,

про апдейт - это твой очередной высер и просто отрицание реальности.

Отличная аргументация! Продолжай!

[xmoonlight]

Bavashi, Хех...)) Ну, главное - чтобы ты в это всё верил и думал, что всё именно так! ))

[xmoonlight]

Bavashi, Посмотрим.

[xmoonlight]

Bavashi, Ну, есть как есть. Минусуют все на хабре. Напиши пост и узнаешь.

[xmoonlight]

Bavashi, почитай вот тут
ТОП-10 самых заминусованных комментариев в 2019 году

[xmoonlight]

Bavashi, Твой профиль на хабре: тут.

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

Т.е., ни в чём не разобрался, а других - попусту гнобишь...

[xmoonlight]

Bavashi,

что тебя не найду в списке. Видимо, у тебя еще все впереди. Хотя причем тут комментарии и карма ...

НЕ-е-е! ) Впереди - это как раз у тебя! (ну, или оставайся DUMMY :)

[xmoonlight]

Bavashi,

Ты не понимаешь главное, выйти к доске и обосраться - каждый может, но только ты выдаешь это за достижение.

Не только я... Ещё много других людей и компаний. Т.к. они что-то пробуют и пытаются делать.
А такие типа тебя - просто боятся, что узнают об их компетентности то, что не должны были узнать. А учиться - не хотят. Зато хамить - их любимое занятие.

[xmoonlight]

Bavashi,

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

Не отстаиваю, а просто указал на то, кто виноват в той ситуации. Виноват - РП-шник (девушка, которая собрала и наняла людей не проверив адекватность и без договора).

[xmoonlight]

Bavashi,

Так где работаешь?

Там где адекватные люди, которые ценят знания, а не хамство.

[xmoonlight]

Bavashi, Ты закончил своё выступление АРЛЕКИН)) или ещё нет?))

[xmoonlight]

Bavashi, ))) Видимо ещё надо покататься тебе по арене))

[xmoonlight]

Bavashi, Не умеешь управлять рисками - не берись за руководство. Это ребёнку понятно.

[Вова Дружаев]

К чему срач - мы все культурные люди ёпта!

Answer 3

[Шохрух Шаймардонов]

Гугл уже 20 с лишним лет существует, а многие до сих пор с ним не сдружились...
https://stackoverflow.com/questions/3502478/top-us...

Comments

[xmoonlight]

тут просто репост линков и ответов с SO с переводом...
очевидно же)

[Шохрух Шаймардонов]

xmoonlight, нет, ну если проблемы у людей были бы с переводом, то это не сюда. А к переводчику. А линки со СО сюда кидать, потому что ТС поленился к гуглу обратиться, это грустно

[xmoonlight]

Шохрух Шаймардонов, имеем то, что имеем... к сожалению...

[FanatPHP]

А, главное, запрос такой сложный, что надо ссылку давать.
Руками очень долго писать

Answer 4

[Сергей Карбивничий]

SELECT * FROM users ORDER BY amount DESC

Comments

[Just OK]

Нет, не то.
Мне нужно по сумме считать.
Т.е. у кого больше сумма заказов больше, тот и топ 1, например