Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кто сталкивался с такой задачей, помогите!
|
|||
|---|---|---|---|
|
#18+
Задача такая, есть например таблица юзеров, состоящая из 10 миллионов записей.. У каждого юзера есть поле, в котором хранится скажем уникальное целое число, указывающее на кол-во баллов. Задача при выборе данных пользователя определить на каком месте он находится в общем списке всех пользователей по этому баллу, НЕ ИСПОЛЬЗУЯ в подзапросе COUNT.. То есть просто это SELECT u.name, u.scores, (SELECT COUNT(id) FROM users WHERE scores>=p.scores) AS rank FROM users WHERE id=3256 Но учитывая объем таблицы и то, что count довольно трудоемкая операция - этот вариант не прокатывает.. Подскажите, как это можно обойти, может какое-то gist-расширение свое написать, или индекс свой, в общем ПОМОГИТЕ! Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2007, 11:21 |
|
||
|
Кто сталкивался с такой задачей, помогите!
|
|||
|---|---|---|---|
|
#18+
TeccillaУ каждого юзера есть поле, в котором хранится скажем уникальное целое число, указывающее на кол-во баллов.Действительно ли кол-во баллов уникально, то есть не может быть двух юзеров с одинаковым кол-вом баллов? Если да, то благодаря чему это имеет место, то есть как именно изменяется кол-во баллов? Может быть в этом случае получиться сделать триггер на некое поле "место юзера". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2007, 13:19 |
|
||
|
Кто сталкивался с такой задачей, помогите!
|
|||
|---|---|---|---|
|
#18+
Уникальность просто для упрощения задачи, скажем в дейтинге при поднятии анкеты наверх туда пишется время поднятия с учетом миллисекунд - этого в принципе достаточно чтобы уникальность сохранить.. Но это опять же только для примера.. Если вводить какое-то поле, которое указывало бы на место, то получится, что нужно будет не только его апдейтить при изменении, а всех кого измененная позиция затрагивает, то есть если я был на месте 1000000 а стал на первых, надо сместить всех с первого по миллион на единицу вниз, а это нереально при таких объемах данных.. Пока в принципе это реализовано отдельной таблицей, скажем ranks (id serial, uid) и периодически выполняются следующие операции: - Очищаем таблицу ranks - Устанавливаем текущее значение последовательности ranks_id_seq в 1. - Вставляем в таблицу ranks выборку из таблицы users, отсортированную по scores DESC В итоге получаем новую таблицу ranks где id - указывает на позицию в листинге юзера с uid, и при выборке данных из юзеров через LEFT JOIN ranks по uid получаем его позицию.. Но хочется более красивого решения:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2007, 14:31 |
|
||
|
Кто сталкивался с такой задачей, помогите!
|
|||
|---|---|---|---|
|
#18+
Если для score ограничен диапазон, и распределение более-менее равномерное, то можно ввести масштаб _SCALE_, таким образом уменьшая этот диапазон на порядки Код: plaintext Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2007, 16:00 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34601996&tid=2005348]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
43ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 252ms |
| total: | 349ms |

| 0 / 0 |
