Как в одном sql запросе увязать данные из 3-х таблиц?

Есть три таблички
ID PRIBITIE
1 01.01.2011 00:00:00
1 01.01.2011 00:00:00
1 02.01.2011 00:00:00
2 03.01.2011 00:00:00
2 04.01.2011 00:00:00
2 06.01.2011 00:00:00
2 09.01.2011 00:00:00
ID POKUPKA
1 01.01.2011 06:00:00
1 02.01.2011 03:00:00
2 03.01.2011 10:00:00
2 04.01.2011 12:00:00
2 07.01.2011 15:00:00
2 07.01.2011 15:00:00
1 01.01.2011 06:00:00
2 10.01.2011 01:01:02
ID OTPRAVLENIE
1 01.01.2011 12:00:00
1 02.01.2011 13:00:00
2 03.01.2011 11:00:00
2 05.01.2011 15:00:00
2 05.01.2011 15:00:00
2 08.01.2011 16:00:00
2 11.01.2011 09:00:00
1 01.01.2011 5:00:00

Как корректно написать sql-запрос который вывел бы данные об прибытии, покупке отправлении, для одного id в одной строке. События не обязательно происходят в один день. Дубликатов быть не должно.
Результат выполнения запроса должен быть вот таким:
ID PRIBITIR POKUPKA OTPRAVLENIE
1 01.01.2011 00:00:00 01.01.2011 06:00:00 01.01.2011 12:00:00
1 02.01.2011 00:00:00 02.01.2011 03:00:00 02.01.2011 13:00:00
2 03.01.2011 00:00:00 03.01.2011 10:00:00 03.01.2011 11:00:00
2 04.01.2011 00:00:00 04.01.2011 12:00:00 05.01.2011 15:00:00
2 06.01.2011 00:00:00 07.01.2011 15:00:00 08.01.2011 16:00:00
2 09.01.2011 00:00:00 10.01.2011 01:01:02 11.01.2011 09:00:00

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

до чего смог досямкать, но нифига не оно
SELECT prib.id,prib.pribitie,pok.pokupka,otpr.otpravlenie
FROM
(
SELECT DISTINCT * FROM PRIBITIE
) as prib
INNER JOIN POKUPKA as pok
ON
(
prib.id = pok.id
AND
prib.pribitie < pok.pokupka
)
INNER JOIN OTPRAVLENIE as otpr
ON
(
pok.id = otpr.id
AND
pok.pokupka < otpr.otpravlenie
)

а структуру таблиц уже ессесно не переделать?

Не понял. А что это за ID в первой колонке, который повторяется постоянно в одной и той же таблице? И по каким признакам ты объединять собираешься, чтобы собрать данные для результирующего запроса?

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

table1
table2
table3

SELECT *
FROM table1, table2, table3
WHERE id.table1 = id.table2 = id.table3
GROYP BY поле которое уникально (время вроде. судя по таблице. если и дата то GROYP BY field1, field2)

попробуй

bari писал:

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

Ну это я все понял, не тупой. Просто хочу, чтобы он сам сформулировал, хоть на пальцах - по каким признакам он собирается объединять данные из таблиц. А то вон FXIX уже по дате собирает, а в условиях вроде про дату сказано, что она какой угодно может быть

Как бонус - пока сформулирует уже, глядишь, и решит задачу ))

2bari
Не, уже не переделать...

Dr.Syshalt
Мне думается по связке хронологии дат и ID.
Например ID = 1
прибыл 01.01.2011 00:00:00
сделал покупку 01.01.2011 06:00:00
отбыл 01.01.2011 12:00:00
То есть смотрим ближайшую дату в следующей таблице по данному ID, и больше уже не учитываем эту связку...
Если в таблице две даты с одинаковым ID то по DISTINCT, например, отфильтровываем лишнее, оставляем только уникальные записи.

Епть, че сразу про не тупых. Мы все не тупые.
Получил, видимо, систему в доработку - вот и мучается.
Еще раз повторю, тут разработано как люди сидят на раб.местах, и что видят то и в базу пишут. Кладовщик, продажник, грузчик+кладовщик, так и таблицы лежат. Если хоть один не то проставит, или вообще забьет проставлять, всё - кирдык, SQL не вытянет.

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

Lamagro писал:

Например ID = 1 прибыл 01.01.2011 00:00:00 сделал покупку 01.01.2011 06:00:00 отбыл 01.01.2011 12:00:00

так у тебя из таблиц непонятно какой ID=1 первой таблицы соотносится с ID=1 второй таблицы.

должна быть внешняя таблица ключей для трех таблиц. а тут даже не эмуляция (в каждой таблице ID 1,2,3,4,5...) а просто смешение

ID PRIBITIE
1 01.01.2011 00:00:00
1 01.01.2011 00:00:00
1 02.01.2011 00:00:00

ID POKUPKA
1 01.01.2011 06:00:00
1 02.01.2011 03:00:00
1 01.01.2011 06:00:00

ID OTPRAVLENIE
1 01.01.2011 12:00:00
1 02.01.2011 13:00:00
1 01.01.2011 5:00:00

напиши по какому принципу строки стыкуются в итоговую строку

Lamagro писал:

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

Что значит "больше не учитываем"? То, что попадает в запрос - учитывается только в этом запросе. Ты не можешь в запросе сказать "и чтобы следующие это не учитывали". То есть тебе это "учитываем" нужно где-то хранить по-любому - и, соответственно, менять таблицы. То есть по-хорошему - вводить какое-то понятие transaction/order/operation ID, и уже через него объединять таблицы при выводе - через элементарный JOIN. И будет видна вся история операции. И будет видно, если что-то проебалось и не отгружено клиенту. И много чего еще хорошего будет. Как-то софт соответственно переписывать, чтобы этот ID фигурировал во всех операциях. Как без этого? А тут, в самом деле, кто-то забудет данные внести - и пиздец, ищи потом, что и куда ушло, а как у тебя все поползет - то это мама не горюй...

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

Lamagro писал:

а вариант решения есть именно одним запросом...

возможно что и есть, сейчас, а потом не будет
база хоть в чем? сдается что не mysql

mssql под винду...

Lamagro писал:

а вариант решения есть именно одним запросом...

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

bari писал:

возможно что и есть...

ну вот я и обратился...

Dr.Syshalt писал:

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

http://habrahabr.ru/blogs/mysql/44807/

Lamagro писал:

http://habrahabr.ru/blogs/mysql/44807/

Ну спасибо тебе за ссылку на журнал Мурзилка, только зачем оно мне? Я тебе тоже могу кинуть

http://dev.mysql.com/doc/refman/5.0/en/join.html

А для продвинутых - и это

http://en.wikipedia.org/wiki/Relational_algebra

могу учебников подкинуть. Почитаешь?

Хороший топик на хабре кста
порадовали такие моменты:

Цитата:

оптимизатор оценивает стоимость различных планов и выбирает с наименьшей стоимостью

Цитата:

бесценный линк про JOINы http://www.codinghorror.com/blog/2007/10/a-visual-explanation-of-sql-joins.html

- палим доменное имя

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

ТС, не горюй, есть решение, чую. Особенно если MSSQL. Надо только включить дзенмод и "вспомнить всё".

ой ну все накинулись - шапками закидали
там просто так запросто написано селект по селекту )

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

да почему накинулись, советы добрые даем, мож с подъебом и сарказмом, но от всего сердца, мы такие
подозреваю эту задачку на олимпиаде по БД, минут за 5 школьник решит, лет 16-ти, особенно практикующий с MS SQL
но, увы, "если бы молодость знала, если бы старость могла"
даже если с боем найдешь решение, потом, через полгода к примеру, сам на него выпучишься и матом покроешь)
просто, логично, минимум platform-specific - это куда правильней