Привет всем. У меня вопрос, у меня есть некий набор айдишников, допустим (1,2,3,4).
Я извлекаю все строки таблицы , в которых айди входит в это множество:

select * from user where `id` in (1,2,3,4) 

А вот теперь соственно вопрос: как мне упорядочить мои строки по порядку следования айдишников в запросе? 
При чем айдишники могут идти совершенно случайно, например (3,2,4,1) и при запросе я хочу получить ответ в таком порядке:

3 юзер с третим айдишником вася
2 юзер со вторым айдишником петя
4 юзер с четвертым айдишником котя
1 юзер с первым айдишником саша

Можно ли это вообще и если да, то как?

flashaa, нормального решения этого нет. А собственно зачем это? Лучше упорядочить строку с id которая идет в запрос. 

Как вариант,

flashaa, упорядочнить можно следующим образом

Cпасибо большое.
А упорядочить надо так потому сначала было несколько пользователей объединенных по общему полю (допустим user.active_room) - эти пользователи являлись участниками ОДНОЙ общей сущности,  и выборка этих пользователей осуществлялась значению ПОЛЬЗОВАТЕЛЬСКОГО поля.
Далее эта сущность становится недействительна, допустим закрывается некая комната переговоров с этими пользователями - 
cами пользователи высвобождаются  - их поле active_room становится нейтральным, но при этом необходимо сохранить для истории кто из пользователей был в этой комнате и в каком порядке на момент закрытия -
для этой цели я не придумал ничего другого как взять все АЙДИ этих пользователей, собрать в масиив, затем
в строку с разделителями "|" - получил  строку 4|3|2|1|5 и запихал ее в поле room.history закрытой комнаты.

Теперь, чтобы посмотреть кто из пользователей был в той комнате на момент закрытия, скрипт выполняет обратную операцию - получает этот набор айдишников из строки 4|3|2|1|5, 
далее  с помощью запроса 

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

Это сообщение отредактировал(а) flashaa - 28.6.2007, 19:26

ИМХО, тогда лучше сделать отдельную таблицу history с примерно такой структурой:


И выборка нужных данных будет гораздо проще и быстрее.

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

Добавлено через 5 минут и 25 секунд
Кстати тут же позвольте спросить попутный вопрос: 
как лучше сделать? - много простых запросов к бд или один всеобмлющий запрос и его разбор в PHP.

Это сообщение отредактировал(а) flashaa - 28.6.2007, 23:10

flashaa, в примере mishaSL на одну комнату приходится столько записей, сколько в ней было пользователей. А их порядок определяется полем order_user. И умещать информацию об одной комнате в одну строку не приходится. Запрос:



Добавлено через 3 минуты и 26 секунд
Как правило, один запрос сработает быстрее. Как в самой в базе, так и из-за того, что не придется по нескольку раз передавать данные между базой и скриптом.

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

Не всегда. К тому же часто (в отношении хостеров, правельнее сказать почти всегда) БД и веб-сервер находятся на одной физической машине и передача данных занимает минимальное время. В данном случае все зависит от конкретного запроса. Так например, объединение таблиц не по индексным полям займет очень много ресурсов. В тоже время выборка из одной таблицы по примари будет максимально быстрой.

Очень часто максимальной производительности можно достичь при помощи хранимых процедур. Т.е. все быстрые и маленькие выборки + некоторая логика и выборка из объемной таблицы по индексированным полям будет происходить в БД.

Это сообщение отредактировал(а) sTa1kEr - 29.6.2007, 00:01

По поводу хранимых процедур согласна на 100%. Несколько раз в postgres ощутимо уменьшала время таким образом. Жаль, в MySQL недоступно

А LIMIT сильно повышает производительность?

И после вот таких запросов 



Как извлекать результат? Так же как и без COUNT  ? т.е. mysql_result($r,$i,"user_name") ? Только теперь вместо набор юзернеймов будет одно число , которое показывает их количество?

Это сообщение отредактировал(а) flashaa - 29.6.2007, 00:26

Почему же? Начиная с 5ой версии доступно.
Stored Procedures and Functions

Да, если не используется сложная выборка.


Нет, в данном случае для поля надо задавать Alias.
Или обращаться по индексу.


Это сообщение отредактировал(а) sTa1kEr - 29.6.2007, 00:44

Модератор: Пожалуйста, один топик - один вопрос.!!

А если один пользователь был во многих комнатах? 
Тогда придётся скидывать каждогого пользователя из каждой комнаты в отдельную строку - очень много лишней информации