Помогите составить sql запрос

Есть 2 таблицы
в одной хронятся пользователи (id,name,email и тд)
в другой хронятся сообщения (id, user_id(кто отправил), recipient_id(кому отправил),messages,data )
нужно сделать контактный лист.
Тоесть чтобы выводились все с кем переписывался user_id с сортировкой по дате

Использую mysql

Что то вроде такого...



где t1 и t2 это таблицы с информацией о пользователях и сообщениях соответственно, а 'user' - пользователь, "для которого" формируется запрос.

Это сообщение отредактировал(а) Gluttton - 31.8.2009, 23:15

написал так


и не катит. или я где то ошибся???

PS :user_id  глобальная переменная определяющая нашего текущего пользователя

Это сообщение отредактировал(а) MrDmitry - 31.8.2009, 23:37

Выполняется с ошибкой или возвращает не те данные, которые ожидаються?

не каких визуальных ошибок нет. Возвращается пустая страница без данных. Вывожу правельно

В таком случае, прошу показать на каких тестовых данных тестируется запрос (можно не все, а часть  ), в следующем виде:
1. Содержимое таблицы пользователей.
2. Содержимое таблицы сообщений.
3. Ожидаемые данные.
4. Полученые даные.

messages




user

i
ожидалось что выведется следующий список

1 1 
2 2
3 3
4 4


не вывелось ни чего

PS цыфры это фамилии Имя Отчество 

так все разобрался sql работает но выводит не то что нужно.
Вот предствате себе записную книжку в телефоне. Там вить редко когда бывают повторяющиеся сообщения. Мне нужно вывести список всех с кем пользователь обменивался сообщениями. Каждый кто поподает в список выводится 1 раз

(в это скрипте выводились те с кем пользователь переписывался. при чем пользователи повторялись в списки :()

В синтаксисе. Двоеточие убери.
Но чтобы каждый абонент был в списке только 1 раз - нужно в запрос добавить группировку по абонентам, и брать соотв. дату связи (первую либо последнюю).

вслучае если у пользователя нет сообшений то результат будет 0 строк, что бы этого избежать, замените INNER JOIN на LEFT JOIN.


если вы про это ":user_id", то это параметр запроса, только не глобальный как выразился ТС - область его видимости не выходит за пределы данного запроса.

Это сообщение отредактировал(а) DimW - 1.9.2009, 08:37

Зависит от диалекта - который не указан.

ну с этим ни кто и не спорит.

снова не то

в бд




выводит 

Имя    Фамилия
 4             4
 5             5

Нужно 

Имя    Фамилия
4            4
5            5
6            6

То есть грубо говоря выводится список исходящих сообщений а не контакты (

Хотя я бы сказал зависит от способа доступа.

Так всё таки, что же требуется?

Я наверное не правильно выразился
Сейчас постараюсь обьяснить

есть 2 списка
в одном выводится список всех сообщений которые пришли нам (Входящие)
в другом выводится список сообщений которые отправил пользователь (Исходящие)
так вот нужно вывести всех пользователей из спиков Входящие,Исходящие, чтоб выводились все пользователи которые попали в эти списки, но выводились 1 раз, тоесть формируется список контактов

вот sql запрос списка "Входящие"


вот sql запрос списка "Исходящие"


Это сообщение отредактировал(а) MrDmitry - 1.9.2009, 11:09

Ну дык, и UNION тебе в руки  ...
(Между запросами, для объединения их результатов необходимо поместить UNION - в тех случаях, когда необходимо, что бы результаты не повторялись (т.е. отображались только уникальные записи) или UNION ALL - когда необходимо, что бы отображались все данные).

Akina,  в данном случае distinct это излишество.

щас попробую

Добавлено через 12 минут и 54 секунды
Сообвственно вот что выдалось
The used SELECT statements have a different number rof colomns

Это сообщение отредактировал(а) MrDmitry - 1.9.2009, 11:34

собственно покажите что запускали.

Угу. Но на время выполнения это не повлияет, а направление мысли покажет.

вот так писал

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


можно было бы проверить и поспорить, но что то лениво  (да и БД будет другая)

Это сообщение отредактировал(а) DimW - 1.9.2009, 13:05

я из его примера не понел что есть 
sender_id и mess

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

ну если recipient_id у вас получатели(входящие), то несложно догадаться что sender_id отправители(исходящие),  mess это алиас подзапроса(внимательней посмотрите запрос).

Кстати, пытаясь это продемонстрировать, наткнулся на багу в 11g )
DimW, можешь прогнать на десятке, девятке (у меня дома не стоит)?

есть мысли почему так?

Баг, не иначе... ;)
ЦБО обязан был выполнить дистинкт если ограничение уникальности активно но не валидировано. (я однажды на поиск причины по какой мне давался не правильный план убил безумно много времени, пока не выяснил что констрейнты были включены без валидации).

Собсно я пытался покзать результат работы этого скрипта, но на 11м он мне вернул одинаковые планы, ввиду бага. На десятке, девятке, уверен планы будут разные:


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

да ладно это мелочи посравнению с - тынц   

блин я туплю жестко
У меня же нет столбца sender_id 
что за место этого подставлять? ((((

Добавлено через 3 минуты и 53 секунды
и еще  на что заменить ORDER BY чтоб сортировка была не по убыванию а возростанию
Тоесть чтоб сначало выводилось самое ранне сообщение затем меннее ранее и т.д

сорри глюканула 2 раза наверно отправить сообщение нажал

Это сообщение отредактировал(а) MrDmitry - 1.9.2009, 14:28

m.user_id


order by ПОЛЕ asc - по возрастанию
order by ПОЛЕ desc - по убыванию

по умолчанию должно от меньшего к большему.

Все всем огромное спасибо