Здравствуйте, vdimas, Вы писали:

V>MS SQL справлялся с такими джоинами еще с версии 6.5, т.е. с 96-го года, чем нехило меня удивил.
V>Бо до этого я наблюдал в других диалектах SQL только джоины по строгому равенству inner, либо outer left/right.
V>FULL не считается, бо он во многих диалектах получается "сам" и без join.
V>Собсно, удивило то, что в MS SQL план запроса не зависел от того, использовалась ли для обсуждаемых неординарных соединений конструкция join, или простое where.
V>Т.е. это уже было дело вкусовщины автора запроса.
Отож. Известный факт, во всех учебниках по проектированию RDBMS описан.
V>Но факт остаётся фактом, такое соединение по групповой операции заметно тяжелее, чем обычный джоин.
S>>Вот тут было бы уместно показать определение таблиц, запрос, и его план.
V>Ничего военного там нет — обычный составной кластерный индекс {код_валюты, дата_изменения_курса}, бо ширина индекса практически равна ширине таблицы.
Ещё раз поясню природу вопроса: "тяжесть" запроса определяется исключительно операциями, из которых состоит план запроса.
Удивительно не то, что MS SQL порождает одинаковый план для where, для join, и для subselect.
А то, что при грамотном построении индексов, порождается одинаковый план что для =, что для max(...) where ...<=...
Не надо мне рассказывать про то, как вы боролись с замедлением таких запросов.
Лучше расскажите, откуда берётся замедление в пару секунд при джойне с историческими данными.

На примере плана запроса "если бы курсы были на каждый день" и плана запроса для "но курс на данную дату нужно вычислять по max(change_date) where change_date<=doc_date."
Ибо не должно там быть никаких тормозов, про которые вы рассказываете.

Оффтоп: поймите, когда я вижу вот такие вот фразы в форумных постах, то возникает ощущение катастрофической разницы во владении предметом между мной и автором поста.
И мне каждый раз интересно — вдруг это я тупой чего-то интересного не знаю о СУБД. Не разочаровывайте меня — покажите, откуда могут взяться тормоза в современном движке, который уж 15 лет как перестал выполнять full scan в таких подзапросах.