Новая тема   Ответить

 Lamagro
Есть три таблички
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

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

 Lamagro
до чего смог досямкать, но нифига не оно
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
)

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

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

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

 FXIX
table1
table2
table3

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

попробуй

 Dr.Syshalt
bari писал:

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

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

 Lamagro
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, например, отфильтровываем лишнее, оставляем только уникальные записи.

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

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

 FXIX
Lamagro писал:

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

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

 FXIX
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

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

 Dr.Syshalt
Lamagro писал:

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

 Lamagro

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

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

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

 Dr.Syshalt
Lamagro писал:

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

 Lamagro
bari писал: ну вот я и обратился...

 Lamagro
Dr.Syshalt писал:
http://habrahabr.ru/blogs/mysql/44807/

 Dr.Syshalt
Lamagro писал:

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

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

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

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

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

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

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

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

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

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

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