пот держит?
Настолько альтруистичный, что даже зарегался на форуме, чтоб дать возможность...
Достаать до зве-е-зды..
За неимением рабочего кейса дискуссию предлагаю свернуть (точнее нерабочего.. - т.е. чтоб запрос выдавал некорректный результат)
ОК, =)
Если задумка - вывести что-то вроде 2-3, то "-" (минус.. разделитель то есть) лучше ставить первым аргументом. Для "корректного" сравнения можно использовать zerofill или LPAD, если нужно обойтись без изменения таблицы.. А вот оптимальность такого запроса...
Если не ошибаюсь, индекс topic_id, pid может быть полезен в обоих случаях. Если будет использоваться в блоке на всех страницах или на главной, имеет смысл кэшировать...
p.s. edogs, немного смущает множественное число в Ваших сообщениях..
Пример "меньшинства" будет?
На самом деле не могу не согласиться по поводу "случайной" (да чего соглашаться, так в мануале и написано), т.к. для выбора неаггрегированных полей в запросах с GROUP BY используется порядок расположения записей "как есть" (да-да, из той же серии, что и автоинкремент), а они в общем случае не упорядочены (есть, правда, исключения)..
Однако, используя то, что при выборе используется первое из найденных значений в совокупности с заранее упорядоченным набором записей можно получить нужный результат. Вполне возможно, причина в том, что формулировка "indeterminate value" гораздо проще, чем попытка пояснить, почему та или иная запись будет первой..
* Поведение стабильное (больше 6-ти лет точно), логичное и оптимальное (с точки зрения минимизации операций) и я (лично для себя) не вижу никаких причин, по которым разработчики могли бы поменять его. Кому интересно - может заглянуть в код MySQL.
** Естественно, никого не призываю использовать =)
И да.. если 2 записи с максимальным pid, то в предложенном мной варианте, будет выбрано только одно.. то самое, "произвольное" (если не задать дополнительно приоритет)
А можно подробнее?
Видимо, имеется ввиду, что вместо "динамической" картинки, предоставляемой хост-трекером (сторонний сервис для проверки Uptime) используется сохранённый вариант с 99,99% внешне очень похожий по оформлению..
Это примерно как счётчики liveinternet-овские сохранить.. с пяти-шестизначными цифрами... Ну, или фиктивный скрин выдачи Яндекса в портфолио по продвижению положить...
Первая попавшаяся ;) (а в данном случае - с максимальным pid т.к. мы точно знаем, какая строка будет первой для каждого tid в результате выполнения подзапроса)
Т.е. и с деньгами остаться и результат работы использовать?
Смотреть лог ошибок.. Не исключено, что админка "подправлена" до нерабочего состояния.
Или заглянуть в лог ошибок...
Зависит от Вашего уровня.. =)
В любом случае, имеет смысл использовать уже готовые наработки.. Из CMS лучше рассматривать более "кастомизируемые" (ИМХО, Drupal, Modx).. Хотя, я бы выбрал реализацию на одном из фреймворков (опять же, в зависимости от опыта и знаний.. Иметь ввиду, что в таблице перечислены далеко не все. Есть более полный вариант)
Ай-ай.. конечно же..
Во вложенном запросе сортировать по pid:
ORDER BY p.pid DESC
В общем случае - примерно так (сортируем по убыванию, группируем по нужному полю)
SELECT * FROM(SELECT t.*, p.* from topics t INNER JOIN posts p ON p.topic_id = t.tidORDER BY p.topic_id DESC) tGROUP BY tid
