Опять я со своими меньшими значениями в замешательстве  
Есть таблица table, поле id уникальное, sub_id неуникальные.
Мне нужно выбрать для каждого из имеющихся sub_id его минимальный id, например, такие данные:

id sub_id
1 1
2 1
3 2
4 2
5 2

результат - строки
1 1
3 2

Запрос, так понимаю, вида:



Проблема в том, что GROUP BY работает как-то без внутренней сортировки и спокойно может выдавать верные с его позиции, но некорректные для моей задачи данные, например

2 1
5 2

Можно как-то указать ему, что он должен группировать все sub_id по минимальному соответствующему id?

ТоляМБА, не работает, т.к., насколько я понимаю, группировка первична  

У меня еще вот такое сработало...


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

А у меня его код все правильно выбирает...

на тестовой таблице? конечно... но на конечно у меня он точно так же работает, как и без MIN
это и не удивительно, все равно что запрос c WHERE условием - MIN уже будет отбирать из того, что удовлетворяет условию (а в данном случае - группировке), а не из всей таблицы

ваш вариант тоже что-то не работает, но ближе уже)))

Добавлено через 5 минут и 6 секунд
Кароче смысл в том, что данные в файле таблицы физически находятся неоднородно (старая большая таблица, где постоянно что-то вставляется / удаляется / редактируется). GROUP BY берет первую попавшуюся строку с sub_id, остальные такие - соответственно, игнорит. В том то и проблема.

Добавлено через 14 минут и 2 секунды
В общем, сделал так:



Не очень, правда, нравится, пусть и решение чисто техническое, не для масс. Но все равно. У кого будет более рациональный вариант - велкам в тему! ;)

Сказки рассказываете. Запрос ТоляМБА даже теоретически не может дать неверные данные, если кто-то не лазил кривыми руками в исходник сервера БД.

Откуда такая информация?

это не "не очень".
Это - в топку.
Таки чем не устроил вариант от ТоляМБА?

Чистая логика. Иначе почему запрос с MIN и без него возвращает одни и те же данные (не с минимальным, а с первым встречающимся значением)?


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



С последующим наложением на его результаты функции MIN(). Если бы не было группировки, тогда да, область действия - все данные. По сути, оно и тут так есть - область действия все данные, но, все данные не с таблицы, а ограниченные работой GROUP BY.

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


Вам следует начать с чтения документации. И предполагать на основе мануала, а не по линиям на потолке.

НЕТ!!!

Задачу "выбрать для каждого из имеющихся sub_id его минимальный id" решает запрос от ТоляМБА. ЖЫРНАЯ ТОЧКА.

Если запрос от Толи твоей задачи не решает, ты ее не верно сформулировал.

Akina, это лишь мои предположения, я же не утверждаю. По любой мелочи так нервничаете? 

Просто не понятно, почяему тогда пример ТоляМБА, не работает с моей таблицей? В криворукости причину искать, конечно, можно... но в данном случае - вряд ли выйдет, там чистый дамп БД одной из крупнейших CMS.

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

Добавлено через 48 секунд

Так, РЕАЛЬНУЮ структуру таблицы и НАСТОЯЩИЙ текст запроса - в студию.

Akina, конечно другая. Все описывать как оно есть было бы долго, я затронул лишь суть проблемы. Ок, если говорите что запрос верный, сейчас еще раз буду все с начала разбирать и смотреть.

Тебе надо решить ПРОБЛЕМУ? да? тогда садись и долго описывай. Не помрёшь. Но и помогать тогда тебе будут именно в решении твоей проблемы, а не хрен знает чего.

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



В таблице stats соответственно есть поле уникальное id, по которому и ведется джоин. Проблема в том, что выбираемые данные s.dat не соответствуют MIN(t.id), а соответствуют тому самому t.id, который возвращается в результате простого GROUP BY (т.е. без MIN(t.id)). Подозреваю, что тут у меня какие-то косяки с логикой запроса.

Вот-вот... выбираемое поле, не использованное в агрегатной функции, обязано включаться в Group By.
У тебя нет ни того, ни другого - строгие СУБД на это откликнутся ошибкой, а мускул в силу гипертрофированной user-friendly просто берёт отфонарное значение.

Хм...  а можно подробней, что сие означает, как следует поступить?

думаю не юзерфрендлести дело.
Скорее всего была какаято техническая трудность в реализации рестрикшна.

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

Это сообщение отредактировал(а) Zloxa - 12.1.2010, 16:31

Zloxa, вариант, но я на данном этапе вот так поступил:

мне кажется, проще будет?

не проще и не правильно.

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

мне кажется что тебе еще слишком многому надо учитсья прежде чем пускаться в рассуждения.

А вот я как раз тоже придерживаюсь противоположного мнения.
Начинал еще в детстве, с Z80, бэйскиов да паскалей, поэтому с теми же типами переменных, их сравнениями и т.д. в вольном пхп путаницы не создаю.
А вот с СУБД не сталкивался.

Вы теперь мне предлагаете изучать классические строгие СУБД для того чтобы потом нормально работать с MySQL?
Это ли не то же самое, что учиться кататься на скейте, чтоб потом хорошо на велосипеде ездить, не находите?

Добавлено @ 16:34

Почему не правильно? Работает корректно.

Это сообщение отредактировал(а) maxipub - 12.1.2010, 16:36

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

Zloxa, так, а в чем там ошибка?  

ПОКА работает корректно... но полагать. что так будет всегда - крайне неразумно.

Akina, так можете объяснить, что не так с самом верхнем запросом на странице? Почему он не работает? И как надо его изменить - как вариант от Zloxa?


А почему так? Мы же применяем необходимую сортировку, после группируем, далее джоин идет уже по чистым данным. Можно хоть пример того, что может привести к сбою?

в ДНК.

Документация запрещает использовать в списке полей select выражения не перечисленные в group by и не являющиеся результатом аггрегатной функции, в случае, если значения этих полей могут быть не однозначны для группы. Маська не несет ответственности за то, что будет возвращать всегда ПЕРВОЕ попавшееся значение. Она обещает вернуть ЛЮБОЕ

тыкать на это место в документации я уже запарился. ИЩИ САМ.

Добавлено @ 16:56

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

Это сообщение отредактировал(а) Zloxa - 12.1.2010, 16:57

Zloxa, ну, а примерчик хоть какой-то для лучшего понимания можете предоставить?

maxipub, зачем? 
Лучше ты мне докажи что я не прав.

Zloxa, занавес!  
Ладно, ребята, благодарю за ваши старания. Буду сам дальше кайфовать.  

Что не так - уже не раз объяснили. Отбрось предрассудки и почитай всё-таки доки.



разворачивается в 

что эквивалентно


При выполнения группировки сортировка имеет полное право рассыпаться - ибо нет никаких оснований её сохранять.
Пример тут не нужен. Достаточно усвоить, что простое 

в двух последовательных запусках имеет полное право выдать записи в РАЗНОМ порядке.
Аналогично

в двух последовательных запусках имеет полное право выдать записи каждой группы в РАЗНОМ порядке.

Нет, сортировка набора в результате группировки - в маське документирована. 
Более того, придуман нелепый воркэраунд с order by null, дабы избежать оверхеда на сортировку.

При отсутствии Order By? я что-то пропустил, кажется.

Вот такой вот юзерфрендель 
Я долго умиляся когда сие выопано было.
Кстати, мне казалось, что ты участвовал в той ветке.

тут

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

Понятно... это я - думал одно, а сказал совсем другое... должно было быть не "в двух последовательных запусках имеет полное право выдать записи каждой группы в РАЗНОМ порядке", а "в двух последовательных запусках имеет полное право обрабатывать записи каждой группы в РАЗНОМ порядке".