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

id | login | time 
1 | log1 | 10 
2 | log1 | 15 
3 | log2 | 100 
4 | log2 | 80 
5 | log3 | 11 
6 | log4 | 8 

Нужно сгруппировать по столбцу login что бы сгруппировалось по максимальному time , вот так 

id | login | time 
3 | log2 | 100 
2 | log1 | 15 
5 | log3 | 11 
6 | log4 | 8 

Подсказали мне вот такой код 

SELECT `login`, max(`time`) AS `time` FROM `tabl` GROUP BY `login` ORDER BY 2 DESC 

Он работает так как мне и было нужно, но есть одно НО 
При этом коде выводится только 2 поля login и time, остальные поля не могу выбрать. 
Подскажите как правильно создать запрос, что бы работал аналогично приведенному выше, 
но что бы можно было делать выборку всех полей. (их больше чем в примере). 
Надеюсь на ваш проффесионализм

Как вариант вот это, точнее результат этого


объединяем с таблицей   tabl по полям тайм и логин.

Добавлено через 1 минуту и 46 секунд
То беж должно выйти что-то типа

Совершенно стандартный подход... сколько тут аналогичных тем... только order by  в подзапросе не нужен...

Пример так, синтаксиса MySQL не знаю:

При таком коде сбивается сортировка вывод идет в хаотичном порядке

stff бабушкин метод



Это сообщение отредактировал(а) Zloxa - 20.2.2011, 13:24

Подвешивает хост

Добавлено через 11 минут и 17 секунд


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

Самостоятельно дописать ордербай - чего не хватает?

Если это совершенно стандартный подход, подсказали бы правильный запрос...

Добавлено через 2 минуты и 20 секунд


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

Я не понял ничегошеньки из сказаного, но мне кажется, что тут нет ни стлова о том, что именно не устраиват в полученном результате, потому у меня возникают сомнения в том, что Вы пытались его изучить.

Порпобуйте упораядочить хаос както так:



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

Добавлено @ 13:49
И, пожалуйса, впредь, постарайтесь воздерживаться от подобных формулировок:



Возможно вы полагаете что так вы можете когонить на чтонить мотивировать. На самом же деле, вы настраиваете против себя тех, кто захочет попытаться оказать Вам помощь.

Это сообщение отредактировал(а) Zloxa - 20.2.2011, 13:59

  
Я на фоксе тестил - отлично работает.  

плохо тестил  

Добавлено через 1 минуту и 17 секунд
в смысле синтаксически вроде все верно, а вот результат только похож на правильный (если я правильно понял ожидания ТС)

Zloxa, 

Жаль что вы не поняли, попробую на пальцах обьяснить

Я от кода ожидаю вот такой вывод

id | login | time 
3 | log2 | 100 
2 | log1 | 15 
5 | log3 | 11 
6 | log4 | 8 

А выводит так

id | login | time 
1 | log1 | 10 
4 | log2 | 80 
5 | log3 | 11 
6 | log4 | 8 

То бишь группирует не по максимальному time и потом сгруппированые результаты так же выводит не в убывающем порядке по колонке time

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

Теперь обьясните мне, почему я должен был воздержаться от обращения к людям, которые хорошо знают MySQL?
Люди которые начинают изучение MySQL не смогут мне помочь в этой ситуации, а методом тыка ставить запросы которые подвешивают хост, нет никакого желания, так как я при этом могу терять посетителей.
P.S Не спрашивайте почему я не делаю это на локальном хосте, есть на это свои причины

Добавлено через 4 минуты и 35 секунд
Данкинг,  Возможно проблема в колличестве строк. Вы тестили при каком колличестве строк?
У меня их на данный момент в таблице около 50,000

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



Я не могу объяснить почему, но прочитав эти формулировки у меня по отношению к вам сфомрировался стойкий негатив. Потому я и рекомендовал Вам воздержаться от подобного тона формулировок. Ваше право пренебречь моими рекомендациями. 


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


Это сообщение отредактировал(а) Zloxa - 20.2.2011, 14:55

Не надо методом тыка. Надо изучать материалы и думать прежде чем делать.  

Добавлено @ 15:04
Этот запрос, кстати, тоже должен бы дать верный результат    

Это сообщение отредактировал(а) Zloxa - 20.2.2011, 15:05

Zloxa, Вставил строку запроса из вашего показа таблицы и о чудо, вывод вышел именно так как мне нужно, но радость моя была кратковременной, в выводе некоторые строки дублируются, не все а некоторые , почему не знаю, вывод получился такой

        ID LOGIN       TIME
---------- ----- ----------
         3 log2         100
         2 log1          15
         2 log1          15
         5 log3          11
         6 log4           8

Да, вот так лучше:



Добавлено через 1 минуту и 32 секунды

Тогда так:

Есть две мысли.
Первая - маловероятная. Id - не уникален а значения log1 различаются русской буквой "o" или же какимнить завершающим пробелом
Вторая - невероятная, что пара (login,time) - не уникальна(при этом id - тоже). Невероятно потому, что Вы утверждали обратное.


Данкинг, так будет работать только если time уникален.

Это сообщение отредактировал(а) Zloxa - 20.2.2011, 15:59

Последний пример не смог заставить работать.

Zloxa, 
time уникален, для значения login
То есть связка login + time уникальна, а сам time имеет повторения для других значений login

Вот все таки мне подсказали код, который работает четко так, как мне было нужно,
вот он


Единственный минус генерация страницы повышена в среднем по сайту генерация ~0,05 а на странице с кодом 0,1
(индексы на поля login и time стоят)

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

Должен стоять на пару и индекс должен быть уникальным.  И нужен этот индекс не для увеличения производительности, а для обеспечения гарантии уникальности пары (login,time).
К сожалению данный тип запросов - не тот случай, когда построение нужного индекса сможет на порядки увеличить производительность. Использование индекса, быть может, позволит лишь слега сократить время вычисления группировки. Еще совсем немного спичек можно было бы сэкономить используя ранее рекомендвоанный мною "бабушкин метод". Однако проза жизни такова, что чем больше даннах подлежащих обработке этим запросом, тем дольше он будет выполняться. И с этим ничего не поделаешь.

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

Zloxa, Вы правы на счет запроса. Тот запрос который я указал, тоже дублирует некоторые строки(((
На счет id вы не правы. Это примари с автоикрементом.
На счет пары login+time,маловероятно что он не уникален. time записывается в формате юникс, если может пользователь сделать два обращения к странице в одну единицу времени то может и не уникальна связка.
На счет индекса. Сделал связку login+time генерация страницы снизилась до 0.05 так что это действенно.
По поводу уникальности связки индекса хорошая идея, щас сделаю индекс уникальным, возможно это и исключит дублирование строк

я лишь хотел обратить ваше внимание, что с разрастанием базы вы все равно получите тут проблему. Если ваша система на столько нагружена, что изменение времени отклика с 0,1 на 0,05 оказывается ощутимым, то такому запросу не место в такой системе.

Это сообщение отредактировал(а) Zloxa - 20.2.2011, 21:23