Форум MySQL

лучше бы за 09.12.2010 в 17:27 :)
За него хоть не так совестно. :)

Сдаюсь :)
Оставим ваш вариант за 10.12.2010 в 17:35.

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

да разве ж?
открываем первый пост, читаем:
нужно сделать выборку всех последних сообщения из переписок конкретного пользователя



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

>PS. Вообще-то здесь с самого первого поста идея как бы неправильная.

Кто б спорил. Но если все время думать за того, кто спрашивает, сам он не начнет думать никогда.

>если вопрос в том чтобы получить последнюю созданную запись в таблице

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

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

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

Смотрите, в аттаче - ситуация, когда дата совпала.
Получается один и тот же пользователь за одну секунду запостил два сообщения. И эти два сообщения моим запросом выведены как максимальные.
Чтобы уменьшить вероятность совпадения, можно сделать тип поля даты int, и забивать это поле временем с микросекундами - microtime(), и тогда забить два сообщения за одну микросекунду это надо будет еще постараться.

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

Если тупо заменить, то вроде как смысл теряется... Или я чего-то недопоняла.
Выбирается ж по максимальной дате, если заменяем date на id, возможен же вариант, когда id будет максимальным, но дата при этом - не максимальная, а нам надо поледние сообщения.

Вы явно меня с кем-то спутали.
Мой ответ был адресован Лене.

ну ведь можешь подсказать если захочешь :)

вот такой запрос получился

SELECT m.* FROM message m WHERE m.id = (SELECT MAX(id) FROM message WHERE (sender=1 OR receiver=1) AND users=m.users) ORDER BY m.date DESC

еще два варианта получилось, но наверно с вложенным запросом будет работать быстрее всего

SELECT max(`date`) max_date, MAX(CONCAT(`date`,' ',`id`,' ',`receiver`,' ',`sender`,' ',`text`)) content FROM `message` WHERE sender=1 OR receiver=1 GROUP BY users ORDER BY max_date DESC

SELECT m.* FROM message m LEFT JOIN message m2 ON ((m2.sender=1 OR m2.receiver=1) AND m2.users=m.users AND m2.date > m.date) WHERE (m.sender=1 OR m.receiver=1) AND m2.id IS NULL ORDER BY m.date DESC

в любом случае поле users нужно

еще появилась мысль вместо дополнительного поля users добавить поле last в котором просто обозначать последнее сообщение в теме

SELECT * FROM message WHERE (sender=1 OR receiver=1) AND last=1 ORDER  BY date DESC

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

UPDATE message SET last=0 WHERE (sender=1 AND receiver=2) OR (sender=2 AND receiver=1)

чтобы затирать пометку последнего сообщения

всем спасибо за интерес к теме, думаю что вопрос полностью исчерпан