Форум MySQL

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

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

У всех кто после - не надо.
У всах кто до - надо.
Но делается это одним запросом.
Ну двумя.


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

LOCK TABLES ; SELECT rate FROM ratings WHERE id = $id ; // определение $max  UPDATE ratings  SET rate = IF(rate = $max; $min; rate+1) WHERE   rate BETWEEN $min AND $max ; UNLOCK TABLES ;

>
>При добавлении нового пользователя опять надо

Той же процедурой.

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

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

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

При добавлении нового пользователя опять надо смотреть куда его впихнуть, так как если наверху имеются "платники" и/или пользователь без фотки, то его надо запихивать куда-то в глубину списка.

В общем проблем прилично :(

>Ну или в отдельной таблице ratings (userid, rate)

(слегка подумав) Пожалуй, это будет самый оптимальный вариант.

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

Ну или в отдельной таблице ratings (userid, rate)

Не совсем правильно выразился. Это скорее не флаг

Вот запрос (убрал не нужные для понимания поля и присоединяемые таблицы):

SELECT t1.name, bla bla , COALESCE(t4.date, t1.sort) as sortdate FROM user_general t1 LEFT JOIN user_up t4 ON (t4.user_id = t1.user_id AND t4.mode = ?i) ORDER BY IF(t1.photos >= 1,0,1),sortdate

user_up имеет вид:

`user_id` int(11) DEFAULT NULL,   `date` int(11) DEFAULT NULL,   `mode` tinyint(1) unsigned DEFAULT '0',

т.е. когда юзер оплачивает поднятие своей анкеты наверх, то его ID вместе с временем и кодом операции (mode = 1 - поднятие по всему альбому, mode = 2 поднятие в выборке по стране, mode = 3 поднятие в выборке по штату и т.д.) записывается в таблицу user_up. А потом эта таблица присоединяется к выборке, чтобы построить и отсортировать список.

Огромная просьба "мелочи" подобного рода указывать в самом начале ;)

$vip  = my1("SELECT vip FROM USERS WHERE userid = $id"); $bias = $vip ? 0 : my1("SELECT COUNT(*) FROM users WHERE vip"); $rating = $bias + my1("SELECT COUNT(*) FROM users WHERE $vip = vip AND id < $id ");

Понятно, что составной индекс на полях vip, id не помешает.
Если флаг хранится в сессии, то первый запрос не требуется.

Так это же совсем другие двое!
Здесь можно безо всякой таблицы парой-тройкой селектов обойтись.
Минутку.

По дате регистрации и по специальному флагу, который кидает людей, оплативших определённую услугу наверх списка.

а по чём? последнее посещение или дата регистрации?