|
|
|
| Вот такой вот вопрос, нужно тасовать каталог ежедневно, чтобы старые записи не уходили в конец
я решил завести отдельное поле по которому происходит организованная сортировка
в итоге просмотр в каталоге по страницам не сбивается, а каждый день по разному сортирует
вот у меня вопрос об эффективном методе, какие лучше случайные числа ставить функцией RAND(), целые от 1 до 1000000 или десятичные от 0 до 1
то есть по каким числам база быстрее сортирует таблицу ???
и какой тип числового поля в этом случае быстрее работает???
спасибо! | |
|
|
|
|
|
|
|
для: AN
(22.02.2010 в 15:25)
| | ауууууууууу
ну че, никто не знает?
я не где не могу найти толковой инфы по этому вопросу | |
|
|
|
|
|
|
|
для: AN
(22.02.2010 в 15:46)
| | это потому, что вопроса нет.
По какому критерию должна выполняться сортировка?
Сразу замечу, что сортировка - воссоздание порядка, а не его разрушение.
Не просто так в SQL она называется order by , то есть по порядку . | |
|
|
|
|
|
|
|
для: Trianon
(22.02.2010 в 16:14)
| | вот я и спрашиваю, какие числа лучше использовать при сортировке ? | |
|
|
|
|
|
|
|
для: AN
(22.02.2010 в 22:10)
| | Смотря в каком порядке Вы хотите видеть результат. | |
|
|
|
|
|
|
|
для: Trianon
(22.02.2010 в 22:13)
| | Человек хотел увидеть, видимо, в случайном | |
|
|
|
|
|
|
|
для: mihdan
(23.02.2010 в 10:20)
| | SQL - детерминированный язык. Он выдает четкие ответы на четкие запросы.
Случайный порядок - для SQL - это фикция.
Тем более, когда требуют какой-то особенный случайный порядок.
Да. Я знаю, что в MySQL есть ORDER BY RAND() в угоду сиюминутному.
Требовать от него каких-то поражающих воображение вероятностных характеристик - наивно.
Тем более - наивно требовать от него скорости. | |
|
|
|
|
|
|
|
для: Trianon
(23.02.2010 в 10:26)
| | >Да. Я знаю, что в MySQL есть ORDER BY RAND() в угоду сиюминутному.
именно поэтому человек и хочет ввести поле rand, которое планирует заполнять при помощи RAND(). Мне кажется что это весьма здравое решение. | |
|
|
|
|
|
|
|
для: Loki
(24.02.2010 в 12:05)
| | RAND() - это псевдофункция именно для ORDER BY.
В остальных контекстах алгоритмическая детерминированность её поведения не гарантирована.
UPD. Насколько я помню.
UPD2. Все несколько по-другому, но хрен редьки не слаще:
With a constant initializer, the seed is initialized once when the statement is compiled, prior to execution. As of MySQL 5.1.16, if a nonconstant initializer (such as a column name) is used as the argument, the seed is initialized with the value for each invocation of RAND(). (One implication of this is that for equal argument values, RAND() will return the same value each time.) From MySQL 5.1.3 to 5.1.15, nonconstant arguments are disallowed. Before that, the effect of using a nonconstant argument is undefined. | |
|
|
|
|
|
|
|
для: Trianon
(24.02.2010 в 12:24)
| | Тут речь не идет о криптографии, так что "честный" random никого не интересует. И если "RAND() - это псевдофункция именно для ORDER BY.", то почему бы ее не использовать "отложенно" - создали с ее помощью индекс и какое-то время пользуемся. | |
|
|
|
|
|
|
|
для: Loki
(24.02.2010 в 12:42)
| | >Тут речь не идет о криптографии, так что "честный" random никого не интересует.
Так а о чем идет речь автор не сказал.
А хорошая статистика нужна не только в криптоприменениях.
И если "RAND() - это псевдофункция именно для ORDER BY.", то почему бы ее не использовать "отложенно" - создали с ее помощью индекс и какое-то время пользуемся.
Вот то, какое время, и хорош ли индекс - автору стоило бы определить. | |
|
|
|
|
|
|
|
для: Trianon
(24.02.2010 в 12:45)
| | >Так а о чем идет речь автор не сказал.
Об этом написано в первой строчке первого поста
>Вот то, какое время, и хорош ли индекс - автору стоило бы определить.
Время использования тоже обозначено в первом посте. Да и требования к "хорошести" индекса тоже - чтобы старые записи имели возможность быть в начале каталога наравне с новыми. | |
|
|
|
|
|
|
|
для: Loki
(24.02.2010 в 13:00)
| | Это не определение.
Если хочется иметь начало размером с весь массив - это профанация. | |
|
|
|
|
|
|
|
для: AN
(22.02.2010 в 15:25)
| | Чтобы увидеть различия, выполните оба запроса и замерьте скорость их выполнения - станет ясно, какой вариант быстрее | |
|
|
|