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



В таблице 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, зачем? 
Лучше ты мне докажи что я не прав.