parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

G_Z 15.04.2009 05:31

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

Там есть вариант где это учитывается.
В несколько запросов.
С жёсткой привязкой к структуре таблицы.
А ещё идентификаторы могут быть не числовыми.

UUID? Ну да, само собой не прокатит.
Не только.
Любые «строки».
Составные ключи, опять же.
Если после WHERE (с индексом, разумеется) под RAND() падают не тысячи строк — нет ничего страшного.
Это самый простой и удобный вариант.

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

К небольшим и средним таблицам, при случайной выборке, практически всегда применяется критерий, потому реально упорядочивается не много данных.
К большим — совсем другой подход: периодическая подготовка случайных данных, отбор в отдельную таблицу, жёсткая оптимизация в несколько запросов и прочее.

А пляски с тремя запросами для доставания случайной заметки из своего блога такой же идиотизм, как ORDER BY RAND() LIMIT 1 без отбора на таблице с миллионом строк.