Помогите пожалуйста, нужно вывести 20 рандомных записей из БД (MySQL) и занести их в массив.
Не понимаю как осуществить, подскажите пожалуйста, заранее спасибо.

что то наподобие

надо определиться. то ли тебе случайные поля одной записи(дикая денормализация?), либо тебе 20 записей.

извиняюсь, 20 столбцов нужно вывести, спасибо MoLex, тогда получается



Получается, что в $result занесся только первый столбик, а вопрос в том, как 'положить' остальные 19 столбиков в массив или просто в переменные?

p.s я только учусь   

Это сообщение отредактировал(а) Sice - 23.12.2008, 14:46

в $result занёсся индификатор выборки, а в $row ты получил первую строку выборки, разбиваемую в массив по полям
чтобы получить все 20, достаточно прокрутить $rows = mysql_fetch_array($result); в цикле. всякий раз в $row будет новая строка


"20 столбцов нужно вывести" - не соответствует тому что предложил Molex

я просто путаю столбцы с полями )))) 

bars, вот смотри, через цикл прогоняем например так:



Как я понял так? А теперь как мне присвоить к каждому полю переменную ?? Не писать же мне еще19 раз этот цикл ? 

Добавлено @ 17:58


Это сообщение отредактировал(а) Sice - 23.12.2008, 18:00

ня, достаточно прочитать книжку по пхп, это ж классический пример. или здесь на форуме порыскать, наверное в каждой второй теме попадается

скажем, так:



конечно надо заменить column1 и т.д. на имена твоих полей

а если не секрет для чего это ? 

наверно, для того чтобы решить задачу топикстартера

gibbzy, ну, типа "20 случайных фото" или "20 произвольных продуктов в категории"

skyboy, можно ещё взять максимальное id и методами php сгенерить случайное число в этом диапазоне. А потом выбрать. 
Я картинки обычно называю id шниками тут и выбирать не нужно 

gibbzy
Гениально. Вместо использования одного быстрого и рабочего mysql запроса, воспользуемся двумя, инициализируем лишний раз генератор случайных чисел, так еще и лишимся стабильности. Браво.

при этом не учитывая, что наличие id=100, не говорит о наличии ста записей

Это какой быстрый и рабочий запрос? 
Этот чтоли? Это самый тормознутый из всех запросов мускула  

Nigel а можешь предложить альтернативу этому запросу, чтобы явно подходила под эту задачу*?

Что-то типа такого

Конечно, нужен ключ по полю id.

меня тут осенила гениальнейшая идея на ноб.премию

смотрю, как тут не первый раз возникают темы про случайную выборку и про то, насколько она тормознутая средствами mysql и подумалось следующее

как бы мы там ни говорили про идеальность, всё равно её не существует, если мы говорим о "случайном" выборе, то на самом деле подразумеваем псевдослучайную последовательность, которая периодически повторяется, но с большим периодом. в конце концов в электронике нет генератора чистой случайности за исключением болометра

итак, вместо того чтобы пользоваться rand можно сконструировать псевдослучайный режим выборки, скажем, так:
условия: при всём уважении, если мы поднимаем что-то, к примеру случайные фотографии или набор новостей, то больше 20-40 смысла нет
отсюда, можно ввести в таблицу поле rnd int в которое при запросах insert и update будет вноситься случайное число. далее, при необходимости случайной выборки мы средствами пхп случайно определяем два-три числовых параметра. допустим: дата, число rnd int и в какую сторону считать выше или ниже. после этого строим запрос по принципу: 

... where date<$rnd_date and rnd>$rnd_int order by rnd desc limit 20

синим и красным отмечены случайные элементы. если элементов не хватает, то надо просто отсчитать в другую сторону, костыль придумать не сложно

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




вот такое вот идея   

Nigel, однако в вырожденном случае(rand() вернуло 1) мы получим выборку из одной записи. сколько бы ни было в таблице. естественно, в реальности все может быть, но поначалу(пока в таблице данных немного) такая накладка вполне может частенько происходить: нужное количество есть, но выводятся не все.

skyboy, http://dev.mysql.com/doc/refman/5.1/en/mat...l#function_rand в неравенстве строго меньше 1.

Nigel, окей. 9 записей всего. надо выбрать максимум 10 случайных. rand() возвращает 0,5. сколько записей из списка id (1,2,3,4,5,6,7,8,9) будет возвращено? готов поспорить, что 5(id: 5,6,7,8,9). Это не то, что десять требуемых, а даже не девять имеющихся. 
итак, продолжим измышления.
пускай, у нас значения id распределены так:
1,2,3,4,5,6,7,8,9,100
вероятность того, что floor(rand() * 100) будет больше 9 высока - 9/10. То есть вероятность 90%, что вместо хотя бы 9 значений будет получено только одно.
или я что-то неверно понимаю?

Добавлено через 2 минуты и 51 секунду
нет, вариантов вижу два: выбрать id в клиента и средствами клиента перемешать/выбрать N требуемых или же "тот самый неэффективный запрос с order by rand()". впорчем, не все так плохо: можно поле "случайное значение для сортировки" записывать в таблицу и обновлять...эээ..ну, раз в час. тогда и индексы используются, и элементы местами меняются, да и клиенты вполне могут не заметить.

Выбрать 10 записей из 9 возможных? Это как? Опечатка, видимо  

skyboy, order by rand() начинает тормозить на 4-5 тыс записях, поэтому приводить в пример таблицу с 5-ю, 10-ю или 20-ю записями не коректно. Примерно из той же оперы: у меня таблица с 3-мя записями, при выборке мускул подлец индексы не использует, щас я ему форс пропишу, чтоб было как надо. 

Воот, ключевое слово здесь обновлять. Если раз в час то это уже не рэндом получается, если меньше, то лишняя нагрузка, костыль имхо.
Тот запрос я привел для примера, он не идеален, есть способ эффективнее.

Это сообщение отредактировал(а) Nigel - 25.12.2008, 02:52

Nigel, сложно возразить. 
Да, приведенный тобой запрос быстрее.
Да, таблица с пятью записями маловероятно появится в реальном проекте. 
Но, с другой стороны:
- если имеется значительная "дырка" в значениях поля id(массовая чистка контента портала, удаление тестовых данных), то данные, с идентификатором "до дырки" будут выбираться значительно реже тех, что "после дырки"
- данные будут идти подряд(в смысле, выбираются идентификаторы, идущие подряд) - разве это больший "рэндом", чем обновление каждый час?
впрочем, да. согласен. в реальном проекте разработчика должна волновать производительность запроса на 5 тысячах записей, нежели корректность работы.