Имеем таблицу продаж:




Также есть история смены ролей продавца:




То есть, с определенной даты/время у продавца может быть новая роль (например: стажер, продавец, старший продавец).
В таблице продаж ID роли НЕ хранится.

Чтобы понять под какой ролью ROLE_ID был продавец в момент продажи - нужно в ROLE_HISTORY найти запись с наибольшей DT_CHANGE, где DT_CHANGE <= DT_SALE и от этой записи взять NEWROLE_ID.

Как получить сводную информацию:




на чистом ansi sql?

> Corrid ©   (21.12.15 18:29)  

А фиг ты его выполнишь, если у вас больше 1-го продавца, которые строем не ходят.

Может, я чего не понимаю, но почему в ROLE_HISTORY нет ID продавца?

Вот имеем смену роли - запись в ROLE_HISTORY. Как понять, какой именно продавец сменил роль?

А в SALES, наверное, неплохо было бы иметь ID проданного товара?

Кстати, раз в ROLE_HISTORY нет ссылки на продавца, то задача, ИМХО, в такой постановке решения не имеет. Поправьте, если не так.

> Юрий Зотов ©   (21.12.15 22:51) [2]

Да я ж почему в шутку, из-за в потрепаться.
А так в ROLE_HISTORY - ID продавца обязательно, а в SALES, там вариантов достаточно..., количество не нужно, если это PK. как в теме.

В sales ID работника, в ROLE_HISTORY - ID работника, дата, вступление в роль.
Не хватает ID работника в хистори.

ну а если работник один или работа у них никак не пересекается сменно, то можно так (в принципе тут даже id работника не нужен, если указываем на id продажи, просто покажет роль на момент продажи):

> backuper   (21.12.15 23:27) [6]

Ответ не верный, хотели в стандарте SQL, не помню какой последний.

> Ответ не верный, хотели в стандарте SQL, не помню какой
> последний.

Конечно можете написать, я не против.
Развернуть в селект все это чтобы даже на мускле заработало - не сильно много букв надо поменять.

> backuper   (21.12.15 23:37) [8]

Практически все:)

>Может, я чего не понимаю, но
>почему в ROLE_HISTORY
> нет ID продавца?

Прошу прощения, это мой косяк. Конечно же Id продавца есть, должно быть так:

ROLE_HISTORY - PK записи | id продавца | дата/время смены | ID новой роли
ID | SELLER_ID | DT_CHANGE | NEWROLE_ID

>backuper   (21.12.15 23:27) [6]
в этом запросе чудовищно все:
1. не возвращает то, что нужно автору;
2. предполагает наличие одного работника (сказочное допущение);
3. не в чистом ANSI;
4. демонстрирует порочную практику с nolock в MSSQL;
5. и, наконец,  "order by rr.DT_CHANGE desc" - это какой-то запредельный идиотизм. сколько записей вернет группировка? зачем сортировать одно и ту же дату-время?

п. 5 снимается - не заметил группировку по seller_id
добавляется новый п. 5: у двух (10, 1000) сменили роль в одно и то же время - запрос вернет декартово произведение - не бред ли?

> добавляется новый п. 5: у двух (10, 1000) сменили роль в
> одно и то же время - запрос вернет декартово произведение
> - не бред ли?

смотреть еще раз внимательно

select
 S.SELLER_ID, R.NEWROLE_ID, S.DT_SALE, S.CNT
where
 R.SELLER_ID = S.SELLER_ID and R.DT_CHANGE =
(select
 max(DT_CHANGE) from ROLE_HISTORY T
where
 T.SELLER_ID = S.SELLER_ID and T.DT_CHANGE <= S.DT_SALE
)
order by S.SELLLER_ID

ANSI, ты, видимо, пропустил строчку:

...
from SALES S
...

Но в подзапросе, например, Oracle не видит внешние таблицы (то есть, соответственно S).
Разве в ansi sql так можно?

Пропустил, конечно.

select
 S.SELLER_ID, R.NEWROLE_ID, S.DT_SALE, S.CNT
from
 SALES S, ROLE_HISTORY R
... далее по тексту.

Насколько понимаю, такой запрос - это классика (хотя по скорости, наверное, не лучший).

>backuper   (22.12.15 09:41) [13]
смотрите внимательно:
у двух РАЗНЫХ seller_id одинаковое значение dt_change;
=> данные задвоятся

>ANSI   (22.12.15 19:30) [16]
ещё раз подумайте:
1. объединяете SALES, ROLE_HISTORY;
2. снова заходите в ROLE_HISTORY, чтобы получить максимальный DT_CHANGE.

можно обойтись одним обращением к ROLE_HISTORY

>Corrid ©   (22.12.15 18:22) [15]
>Но в подзапросе, например, Oracle не видит внешние таблицы (то есть, >соответственно S).
это коррелированный подзапрос
и Oracle видит S, и стандарт ANSI не против