В задании потенциального работодателя:
Оптимизируйте, пожалуйста, нижеприведенный запрос:
ВЫБРАТЬ
   КурсыВалютСрезПоследних.Валюта,
   КурсыВалютСрезПоследних.Курс
ИЗ РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних
ГДЕ КурсыВалютСрезПоследних.Валюта В(&Валюты)

Ответил:
ВЫБРАТЬ Валюта, Курс ИЗ РегистрСведений.КурсыВалют.СрезПоследних(, Валюта В (&Валюты))

Получил минус. Может кто подскажет, как такой запрос оптимизировать?

(0) ...СрезПоследних параметров не принимает?

(1) с чего так?

(0) не нужен тебе такой работодатель....

(1) да вы шо!, а было удобно

(3)+100, тока хотел написать))))

(3) +1

(3), (5) но интересно узнать, что у них за ответ...

(7) в цикле

(7) Именно.

(0) не пережиывай, ты просто работодателю не понравился ;)

(0) Я бы еще "&Период" запихал

Условие должно быть в параметрах виртуальной таблицы

ВЫБРАТЬ
   КурсыВалютСрезПоследних.Валюта,
   КурсыВалютСрезПоследних.Курс
ИЗ РегистрСведений.КурсыВалют.СрезПоследних (,КурсыВалютСрезПоследних.Валюта В(&Валюты)) КАК КурсыВалютСрезПоследних

(2) дык и мне интересно стало...

(8), (9) согласен, но нам так не показали.

Период определенно нужен там

+(10) упс, кажись я был нетактичен, прошу прощения

(11) это уже меняет смысл запроса.

Не всегда можно оптимизировать запрос не зная задачу

(15)Его не было, и вот он вдруг стал нужен?

(0) Формально запрос оптимизирован, это факт

(12) какая разница - в этом случае все равно

(11) В исходном тексте даты среза нет.

(18) если речь идет об оптимальности без изменения смысла запроса, то кнотекст не важен...

(0) Вообще-то СрезПоследних всегда должен иметь параметр Период (дату среза)


ВЫБРАТЬ
   КурсыВалютСрезПоследних.Валюта,
   КурсыВалютСрезПоследних.Курс
ИЗ
   РегистрСведений.КурсыВалют.СрезПоследних(&Период, Курс В (&Валюта)) КАК КурсыВалютСрезПоследних

А я бы вообще отказался выполнять такое задание т.к. ОПТИМИЗАЦИЯ, если она делается именно для получения результата, а не для понтов, выполняется В КОНКРЕТНЫХ СИТУАЦИЯХ.
Запрос, прежде чем выполниться в субд проходит через
сервер предприятия, где переводится в SQL, а уж после в самом SQL (если речь конечно идет о клиент-серверном режиме работы)оптимизируется.
В конечном  итоге различные варианты запроса написанного на языке 1С могут транслироваться в один и тот же запрос SQL и на оборот!

так что в топку такие задачи

(24) ваще-т непонятно что такое "Курс" в Курс В (&Валюта)

(25) А если база файловая?

(25)Ну условие-то в параметры перенести - это святое

(24) кому это он должен? Просто если не поставить параметр период, то будет использовать что-то вроде 3999 года.

(25) нормальная проверка на вшивость :-)

Тут смысл убрать из Где во внутрь виртуальной таблицы и учесть, что СрезПоследних должен иметь период

Может у них так:

ВЫБРАТЬ
       КурсыВалютСрезПоследних.Курс
    ИЗ
       Справочник.Валюты КАК Валюты
           ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних
           ПО КурсыВалютСрезПоследних.Валюта = Валюты.Ссылка
    ГДЕ
       Валюты.Ссылка В(&Валюты)

(24) не гони...

(24) Период необязателен. Без даты - актуальный.

(27) а если файловая, то посоветовать переходить на серверную версию и не ипать мозг.
Преимущество ЛЮБОГО из вариантов со 100% уверенностью можно получить только взяв и измерив в каждом конкретном случае время выполнения.

(34) т.е. я правильно понимаю, что ты это делаешь при каждом написании запроса?

(0) а кто минусы ставил? случайно не тупая кадровичка?

(25) Так можно было отказаться почти от половины задач.

(35)
это - это что?
если под "это" подразумевается измерение скорости получения результата запроса. То да, делаю. Более того, я сначала пишу запрос и смотрю как он будет работать. А после, в случае необходимости, оптимизирую его.

(38) стесняюсь спросить, а как ты определяешь необходимость его оптимизации? У тебя где-то есть табличка с записанным оптимальным временем?

(39) кости кидает

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

(41)Так может пользователю и в (31) нормально?Так и оставлять чтоли?

(42) +1

+43 да и исходный вариант в (0) наверняка не создаст неудобств пользователю.

еще раз повторюсь - ОПТИМИЗАЦИЯ ради ОПТИМИЗАЦИИ - это веселое и абсолютно бессмысленное занятие.
Оптимизация требуется тогда и только тогда, когда какое-то действие или процесс затрудняет работу пользователя.

+(45) конечно при условии, что программист грамотный и не делает явных ляпов.

(45) т.е. в момент написания кода ты абсолютно не заботишься о том, чтобы он был по возможности оптимален. А вопросом этим задаешься только если написанное работает слишком долго. Правильно я понял?

Один и тот же запрос, при разных данных в БД, разном количестве пользователей, при разной текущей нагрузке на БД, разном состоянии актуальности статистики на сервере и т.д. (еще куча параметров)
может работать ПО РАЗНОМУ. В одном случае он будет быстрее, в другом медленнее в третьем они будут равны.
Не существует идеального варианта. Нет его.

(48) Что не отменяет общих рекомендаций. В частности, желательности переноса параметров в виртуальную таблицу.

(46) вопрос в (0) преследует своей целью показать, насколько программист способен видеть эти явные ляпы. Но что ты ответишь на такой вопрос? Ты ответишь (34). И заставишь человека купить скуль, даже если он по его потребностям нафиг не нужен. Ну просто, чтоб ты мог упражняться в оптимизации запросов там, где посчитаешь это нужным...

(47) я профессионал имеющий хороший опыт.
Когда я пишу я во главу угла ставлю простоту, четкость, логичность кода.
Если (на первом этапе разработке) результат можно достичь простым (с точки зрения кода) решением но более медленным (возможно) или методом сложным, но возможно более быстрым. Я выберу первый вариант.
Оптимизация ТОЛЬКО после.

(48) тогда как ты вообще можешь добиться хоть какой-нибудь оптимальности? Ведь и количество пользователей, и нагрузка на БД, и многие другие параметры постоянно меняются даже для одной и той же БД. Ты будешь переписывать запрос каждый день для его оптимизации?

(50) нет. Я отвечу, что вопрос поставлен не корректно. И к оптимизации никакого отношения эта задача не имеет. Код с параметром виртуальной таблицы или без него, с высокой степенью вероятности, на SQL сервере преобразуется в один и тот же исполняемый код.

(53) чушь... и необразованность

(53) исполняемый код будет разный

+ неграмотность, но собственно другого от 1Снека ждать и не приходиться

(55) а ты профайлер пользовал? Я пользовал, и получаел ОЧЕНЬ удивительные результаты.

А вот задание, решение которого мне было бы очень интересно. Может кто подскажет.
9. В регистре сведений СвязанныеДокументы два индексированных реквизита – Документ1 и Документ2. Нижеприведенный запрос выдает верные результаты. Попробуйте найти возможность оптимизировать его по скорости
ВЫБРАТЬ
   Регистр.Документ1,
   Регистр.Документ2
ИЗ  РегистрСведений.СвязанныеДокументы КАК Регистр
ГДЕ (Регистр.Документ1 В (&СписокДокументов)
ИЛИ Регистр.Документ2 В (&СписокДокументов))

Я ответил:
Если честно, мне бы и в голову не пришло, что этот запрос можно оптимизировать.
Наверное потому, что не слишком четко понимаю, как влияет индексированность полей на скорость выполнения запроса. Да и анализом запросов в профайлере MS SQL не занимался.
Но раз вопрос задан, попробую предположить, что объединение будет быстрее:

ВЫБРАТЬ    
   Документ1 КАК Документ1,
   Документ2 КАК Документ2
ИЗ РегистрСведений. СвязанныеДокументы
ГДЕ Документ1 В (&СписокДокументов)
ОБЪЕДИНИТЬ
ВЫБРАТЬ
   Документ1,
   Документ2
ИЗ РегистрСведений. СвязанныеДокументы
ГДЕ Документ2 В (&СписокДокументов)

(58) объединение будет быстрее

только ОБЪЕДИНИТЬ ВСЕ
нужно было юзать, а на ОБЪЕДИНИТЬ

(59) Минус получил.

(56)
OFF: Зачем нужны секции? -верх грамотности.

Ты вообще похож на троля. В курсе что это форум по 1С?

(58) Где-то уже я это видел )

(60) При ОБЪЕДИНИТЬ ВСЕ будут дубликаты.

(57)
ВЫБРАТЬ

   КурсыВалютСрезПоследних.Валюта,
   КурсыВалютСрезПоследних.Курс
ИЗ
   РегистрСведений.КурсыВалют.СрезПоследних(, Валюта В(&Валюты)) КАК КурсыВалютСрезПоследних


exec sp_executesql N'SELECT
#V8TblAli1_Q_000_T_001._Fld8781RRef AS f_2,
#V8TblAli1_Q_000_T_001._Fld8782 AS f_3
FROM
(
SELECT
_InfoReg8780_IR2._Fld8781RRef AS _Fld8781RRef,
_InfoReg8780_IR2._Fld8782 AS _Fld8782
FROM
(
SELECT
_InfoReg8780._Fld8781RRef AS _Fld8781RRef,
MAX(_InfoReg8780._Period) AS _MAXPERIOD
FROM
_InfoReg8780 WITH(NOLOCK)
WHERE
_InfoReg8780._Fld8781RRef IN (@P1)
GROUP BY
_InfoReg8780._Fld8781RRef
) #V8TblAli1_IR1
INNER JOIN _InfoReg8780 _InfoReg8780_IR2 WITH(NOLOCK)
ON #V8TblAli1_IR1._Fld8781RRef = _InfoReg8780_IR2._Fld8781RRef AND #V8TblAli1_IR1._MAXPERIOD = _InfoReg8780_IR2._Period
) #V8TblAli1_Q_000_T_001',N'@P1 varbinary(16)',0x9FA500000000000011DD7A4D7248BB1C




ВЫБРАТЬ
   КурсыВалютСрезПоследних.Валюта,
   КурсыВалютСрезПоследних.Курс
ИЗ
   РегистрСведений.КурсыВалют.СрезПоследних(,) КАК КурсыВалютСрезПоследних
ГДЕ КурсыВалютСрезПоследних.Валюта В(&Валюты)

exec sp_executesql N'SELECT
#V8TblAli1_Q_000_T_001._Fld8781RRef AS f_2,
#V8TblAli1_Q_000_T_001._Fld8782 AS f_3
FROM
(
SELECT
_InfoReg8780_IR2._Fld8781RRef AS _Fld8781RRef,
_InfoReg8780_IR2._Fld8782 AS _Fld8782
FROM
(
SELECT
_InfoReg8780._Fld8781RRef AS _Fld8781RRef,
MAX(_InfoReg8780._Period) AS _MAXPERIOD
FROM
_InfoReg8780 WITH(NOLOCK)
GROUP BY
_InfoReg8780._Fld8781RRef
) #V8TblAli1_IR1
INNER JOIN _InfoReg8780 _InfoReg8780_IR2 WITH(NOLOCK)
ON #V8TblAli1_IR1._Fld8781RRef = _InfoReg8780_IR2._Fld8781RRef AND #V8TblAli1_IR1._MAXPERIOD = _InfoReg8780_IR2._Period
) #V8TblAli1_Q_000_T_001
WHERE
#V8TblAli1_Q_000_T_001._Fld8781RRef IN (@P1)',N'@P1 varbinary(16)',0x9FA500000000000011DD7A4D7248BB1C

(63) да ты его не слушай. Посмотри какие он темы создает. Судя по всему, он вообще 1С не занимается, а только флудит.

(66) На дубовом тема была с таким вот в точности вопросом.

+(67) правда там не Михаил Козлов был.

(65) молодец. И что?
У Тебя у оптимизатор  еще не имеет статистики по выполнению запроса.
В зависимости от кучи параметров (о которых я писал выше) эти запросы могут меняться. Вплоть до скатывания к прямому перебору.

+(68) http://dff.sytes.net/2075

(0) Я бы ответил также. Если минус заслуженный, то в конторе какие-то мегаоптимизаторы сидят.
(53) В случае конкретно этой виртуальной таблицы точно не знаю. В более сложных виртуальных таблицах (остатков и оборотов, например) используются временные таблицы. Там разница в производительности может составлять порядки. А даже если в этом конкретном случае разницы и не будет, то никто не даст гарантии что в следующем релизе это будет также. Есть чёткие рекомендации от 1С по поводу использования параметров временных таблиц.
(58) Объединение точно не быстрее. Но как этот запрос оптимизировать, ума не приложу. Контора какая-то слишком прохаванная :)

(62) мне уже давным давно нечего спрашивать по 1С

(69) дятел, учи внутреннюю структуру регистров, может тогда дойдет...
хотя вряд ли

(0)
может из-за того, что "кратность" не выбирается? но это, вроде, не относится к оптимизации...

(63) а ОБЪЕДИНИТЬ будет не быстрее ...

(63) кто принимал тест?

(58)
ВЫБРАТЬ
   Регистр.Документ1,
   Регистр.Документ2
ИЗ  РегистрСведений.СвязанныеДокументы КАК Регистр
ГДЕ

Выбор когда (Регистр.Документ1 В (&СписокДокументов) Тогда Истина
Иначе Регистр.Документ2 В (&СписокДокументов))
Конец

в файловой версии быстрее работало в 8.1

(76) см (70)

Похоже на каких-то псевдооптимизаторов. Потому что результаты более тонкой оптимизации сильно зависят от конкретных наборов данных и движка вообще. ИМХО. Получили в своем конкретном случае более быстрый результат на каких-то хитровжаренных запросах, а потом выяснится что они статистику не апдейтили или на файловой прогоняли...

(77) Интересно.

(78) через левое соединение, значит в правильную сторону думал

(79) + Т.е. оптимизация в итоге вполне конкретная, но для общего случая а тем более для тестовых заданий вряд ли катит.

(73) вроде как получается, что дятел ты сам.
Первое: я ни где не говорил, что не надо использовать параметры виртуальных таблиц (т.к. таблица виртуальная, то она создается при обращении к ней, и чем больше условий будет задано на данном этапе, тем выше шанс, что запрос будет работать быстрее).
Второе: есть рекомендации 1С, и им надо следовать - это не только хороший тон, но а так же хороший задел на будущее т.к. версии программ меняются, меняются внутренние механизмы.
Третье: вопрос в (0) в отрыве от контекста (конкретной задачи по ОПТИМИЗАЦИИ) не имеет смысла. Запрос в (0), скорее, относится к знанию рекомендаций 1С, а так же пониманию процессов происходящий на уровне платформы. На что я бы и предложил указать при решении задачи.

(78) через левое соединение, значит в правильную сторону думал
(80) через левое надо было...
ОБЪЕДИНИТЬ слишком долго будет обрабаываться

(83) ты дятел... просто запомни это

[т.к. таблица виртуальная, то она создается при обращении к ней,]

надо будет при встречи 1Сам рассказать пусть поржут

(82) в (70) есть правильный ответ

(83) Масло масленное.
Товарисчу уже все показали на примере (65) - будь там хоть FullScan, но предварительный фильтр вложенного запроса с последующих соединением отработает быстрее, чем соединение с полной таблице и последующий фильтр.

(85) Вижу два предложения по оптимизации. Оба умозрительные, тесты не проводились.

(86) это бесполезно ... до него не дойдет...
у него могучая платформа сам колдуют и знает чего он хочет получить

(87) у Ненавижу1С правильное ;)

(84) <<
[т.к. таблица виртуальная, то она создается при обращении к ней,]

надо будет при встречи 1Сам рассказать пусть поржут
>>

Ничего смешного.

Она, скажем так, не создается, это - фикция. Это фактически результат запроса.

Ты только не путай это понятие с таблицами остатков/оборотов, которые реальны.

(88) "у Ненавижу1С правильное ;)"
Загнать список во временную таблицу и соединением через тоже самое ИЛИ?
Вот не уверен, что в общем случае будет быстрее. Верю, что в каком-то конкретном случае может быть быстрее.

(89) А запрос не к реальной таблице остатков?

(86) Понимаешь, суть того, что я говорил выше сводится к тому, что:
Запрос, написанный на языке 1С, проходит несколько стадий оптимизации. Нельзя сказать, что один и тот же запрос будет всегда выполняться одним и тем же способом непосредственно на sql сервере. Способ выполнения запроса будет зависеть от многих параметров. Выяснить со 100% вероятностью какой запрос будет работать реально быстрее (а не умозрительно) можно только проведя тесты.
На результаты тестов будет влиять конкретные данные. В отрыве от этих данных, сказать что будет быстрее можно только умозрительно без привязки к реальности.
(89) судя по всему (84) путает виртуальные таблицы остатков (которые рассчитываются и хранятся в базе и другие виртуальные таблицы)

(89) я имел ввиду все регистры...
понятно дело, что в случае периодического регистра сведений , там просто идет вложенный запрос...
но и результат для РС будет разные в зависимости от того куда условие давать

(90) условие ИЛИ дает Full Scan

(90) =)
>>Вот не уверен, что в общем случае будет быстрее.
Во первых помещение в темп - это время. Второе - в join

(94) В любом случае без исключений? Буду знать, если так.
Только ведь у Ненавижу1С тоже ИЛИ. Только в джойне.
Оптимизатор конечно в джойнах обычно более уверенно индексы использует, но разница далеко не всегда есть. Были примеры, когда через ГДЕ быстрее отрабатывало.

ппц пошли споры теоретиков. Хотя знать теорию - это хорошо и нужно, но терроризировать нужно до определенного предела.

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

Кстати, Евгений Гилев, очень подробно эту тему объяснял.

так я и не понял, чем дело в (0) кончилось то?

"Высер" то какой-то есть хоть у этой псевдо-оптимизации?

(98) Так и я к тому же, что не вижу явной оптимизации. А что за статья, кстати?

(100) еще раз - ЕВГЕНИЙ Гилев :) Ты путаешь с Гилевым db2 =)
А Евгений рассматривал эту тему в мастер группе. Кстати очень интересно все рассказал и показал. И итог такой: нефих не зная броду, индексировать поля в темпе, т.к. такая оптимизация, сродни (0)

(100)
http://www.gilev.ru/1c/81/index/optimquery.htm
http://www.gilev.ru/1c/81/index/
это наверное он имеет в виду.

(102) извиняюсь, но это - не тот Гилев. Наш Гилев - это который с Фаритом Насиповым курс по программированью сделал.

Гилевых два получилось. И оба одаренные люди.

(103) :)
ну то что я привел тоже интересно.

Короче, так нифига и непонятно с этими заданиями и тем паче с ответами. И еще больше непонятно с вакансией. Либо биллинги на 1С рисовать с заточкой на конкретный движок, либо составитель просто самодовольный Чудак, думающий что постиг дао и жаждущий самоутверждения.

СрезПоследних вообще не быстрая операция посмотрите в профайлере, во что она превращается.
И быстрее будет ВООБЩЕ НЕ ИСПОЛЬЗОВАТЬ срез последних!
Вот, что КАК надо было подойти к задаче, а не переносить в параметры условия :)

Ну, чё, уже 55 поддержавших.
Автор, если ты не врешь, то удачи тебе. Забодай их.

Сори..

Не в ту тему запостил.

Но раз уж зашел к вам, то спрошу (106), а нафиг вообще тогда этот срез последних придумали, как вы думаете? Если он такой страшный и медленный.

Рад, что Гилёвых хоть как то стали различать
а то уже утомили "когда нам ваш диск придет"

(105) что не понятно, спроси

(110) Что бы не городить тоже самое в конструкторе.
Рекомендую посмотреть профайлером, во что превращается срез последних.
Вопросы отпадут.

(113) на маленьких объемах пофиг
на больших объемах совершенное другие проблемы :)

(0) :) Вообще можно ответить тому кто предлагает чего то оптимизировать подождать полгодика дабы SQL сервер статистику поднабрал для оптимизатора.

(106)это справедливо только на больших объемах

а какие там нафиг объемы обычно? мизер

адиэснеги - такие адинэснеги...
(0) ты либо не за это задание минус получил, либо тебя для массовки пригласили заведомо не желая тебя брать или/и как-либо оценивать. Расслабься - shit hapends.

(112) Кого спросить? Для начала интересны правильные ответы на озвученные два задания. Очень интересны хитрые варианты оптимизации, справедливые для любого движка. Не говоря уже о том, что первое задание выглядит классической проверкой на использование параметров виртуальных таблиц и другого ответа при такой вводной ожидать просто глупо.

(119) может быть (112) и есть составитель вопросов?

(120) Тогда он сможет дать ответы.

(121) тоже на это надеюсь.

Еще можно добавить выборку валют в временную таблицу

И вообще трудно оптимизировать запрос оторванный от задачи.

(124) + Я бы сказал это явный и д и о т и з м

(113) Кстати. Во что же такое страшное в профайлере превращается срез последних?
Смотрю в (65), криминала не вижу.

(58) Интересно, все вопросы из данного теста будут выложены на форуме? :) Вроде как нехорошо по отношению к составителю это:( Хотя тест, как я понял, довольно таки давно сделан и многие его уже видели. Я когда отвечал, написал, что через объединение быстрее будет, т.к. скорее всего индекс по Документ1 кластерный и выборка очень быстро отработает. Хз, правильно или нет, по задачам оценку мне не давали, но вцелом тест я прошел, так что вероятность достаточно высокая :)

(127) А! Так это какое-то комплексное тестирование было? В части, скажем, навыков тонкой настройки запросов 1С под MSSQL? Тогда это многое объясняет. Под таким углом задания совсем по-другому выглядят.

У 1сников есть предубеждение насчет точки, может надо было как-то в переменных или где там описать эту штуку чтоб потом везде без них использовать?
РегистрСведений.КурсыВалют.СрезПоследних

(129) Шедеврально.

(130) а мне лень было комментировать...

(126) Криминала нет, пока не сложных RLS. А вот тут план запроса может измениться совсем не в лучшую сторону. И получим TABLE SCAN

(119) я не являюсь составителем вопросов
классический ответ подразумевает не выбирать сначало всю таблицу, а потом делать по ней отбор, а сразу накладывать отбор в виртуальную таблицу

хотя по моей практике иногда есть смысл делать отбор и там, и там
кроме того, ответ существенно будет различаться по субд

не думаю, что найдется много спецов, которые опишут поведение этого запроса под ораклом или дб2

(133) Слава, а соображения исходя из MS SQL какие будут? Ведь 100% опыт подобного у тебя был.

(134) я бы исходил их конкретных условий
а) пользователей 3 человека, объем базы 2 Gb - да пофиг
б) 20 активных юзерей, 20 Gb - если железо тянет, то тоже не принципиально, если не тянет уже, то в виртуальную таблицу засунул отбор
в) 100 пользователей, 100 Gb база - наверно посмотрел бы сначало ЦУПом и профайлером, нужно ли улучшать
в этом случаи скуль на КОНКРЕТНОЙ железке может себя вести ОТЛИЧНО ОТ СОСЕДСКОГО, и универсального ответа нет, все будет определять ПЛАН ЗАПРОСА
г) 500 пользователей, 200GB база - поменял бы MS SQL Server на DB2 и не парился бы :)

(135) А если такое используется в RLS? Мельком на партнерском читал, что это не очень хорошо отрабатывает...

(135) >>в этом случаи скуль на КОНКРЕТНОЙ железке может себя вести ОТЛИЧНО ОТ СОСЕДСКОГО, и универсального ответа нет, все будет определять ПЛАН ЗАПРОСА

Чем определяется план запроса? Конкретой железкой или чем-то еще? Другими словами, есть ли уверенность, что план запроса на одной и той же железке не изменится со временем?

>> Чем определяется план запроса?
Статистикой

(0) А ни кто не заметил, что результат запроса изменится? На ИТС подробно описано, что наложение условия на виртуальную таблицу может к изменению результата запроса, если таблица - срез последних.

(139) Валюта это измерение.
Иди еще раз читай

(0)

может быть вопрос касался более базовых знаний

просто не вытащил представление ссылочных данных

ВЫБРАТЬ
   КурсыВалютСрезПоследних.Валюта,
   Представление(КурсыВалютСрезПоследних.Валюта),
   КурсыВалютСрезПоследних.Курс
ИЗ РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних

Специалисты я смотрю собрались :))
Даже неловко говорить, что в регистре сведений виртуальная таблица _тормозит_, а не ускоряет запрос :))

Для тех, кто на танке, повторяю, _именно_ для регистра сведений.
Да, для регистра накопления, расчета и бухгалтерии  все по-другому.

Все же интересно, что имелось ввиду, может сделать несколько объединений с отбором по одной валюте?

(11) Это ускорение по-твоему? :))

(24) Почему?

+(142) А, кстати, сорри, в (106)-то мысль была :)))

(127) В условии задачи сказано, что Документ1 и Документ2 - это реквизиты, то есть никаким кластерным индексом там и не пахнет..

Что касается варианта с ОБЪЕДИНИТЬ (ВСЕ) - он вообще неправильный, поскольку возвращает другой набор данных.

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

ВЫБРАТЬ
   МАКСИМУМ(КурсыВалют.Период) КАК Период,
   КурсыВалют.Валюта КАК Валюта
ПОМЕСТИТЬ ВТ_ПоследниеДатыКурсов
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
   КурсыВалют.Валюта В(&Валюты)

СГРУППИРОВАТЬ ПО
   КурсыВалют.Валюта
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   КурсыВалют.Валюта,
   КурсыВалют.Курс
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ПоследниеДатыКурсов КАК ВТ_ПоследниеДатыКурсов
       ПО КурсыВалют.Период = ВТ_ПоследниеДатыКурсов.Период
           И КурсыВалют.Валюта = ВТ_ПоследниеДатыКурсов.Валюта

(142)
"Специалисты я смотрю собрались :))
Даже неловко говорить, что в регистре сведений виртуальная таблица _тормозит_, а не ускоряет запрос :))"
Даже неловко спрашивать... Ведь все специалисты давно в курсе... Один я, дурак, остался непросветлённый... Приведите, пожалуйста, альтернативный запрос к основной таблице регистра сведений, который не будет _тормозить_ так, как родная виртуальная таблица среза последних для тестового примера из (0).

(149) Честно скажу, не знаю :))
Может так?

ВЫБРАТЬ
   КурсыВалют.Валюта КАК Валюта,
   МАКСИМУМ(КурсыВалют.Период) КАК Период
ПОМЕСТИТЬ ПериодыВалют
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
   КурсыВалют.Валюта В(&Валюты)

СГРУППИРОВАТЬ ПО
   КурсыВалют.Валюта

ИНДЕКСИРОВАТЬ ПО
   Валюта,
   Период
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   КурсыВалют.Период,
   КурсыВалют.Валюта,
   КурсыВалют.Курс
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПериодыВалют КАК ПериодыВалют
       ПО КурсыВалют.Период = ПериодыВалют.Период
           И КурсыВалют.Валюта = ПериодыВалют.Валюта

Я бы вообще конечно же оптимизировать тут ничего не стал, кроме параметра виртуальной таблицы, но ведь задача думаю была дана не для того, чтобы что-то тут ускорить, а наверное для того, чтобы понять, человек рубит фишку или нет.
Если так, то все грамотно, тест показал, что не рубит :))

+(150) Хе, сначала написал, а потом прочитал (148) :))
Впрочем, в (148) индексирования нет :))

(148)(150)Жесть :)
Надеюсь вы типовые конфы не пишете, и никогда не будете писать...
Ради ускорения в 1 миллионную секунды текст запроса раздут в несколько раз, читаемость так же снизилась в несколько раз...

(148) А я вовсе не уверен, что этот вариант оптимальней по производительности. Почти уверен в обратном. И уж точно зависит от конкретной ситуации и движка. Тестировать лениво, да и времени нет.
(150) Не вижу логики. Честно признаетесь, что не знаете. Но при этом продолжаете ОДНОЗНАЧНО утверждать, что виртуальная таблица среза последних работает не оптимально.

(152) Не ради ускорения, а ради демонстрации понимания принципов работы программы.
В реальности я бы за такое убил бы :))
(153) Я утверждаю не это, а то, что виртуальная таблица регистра сведений работает медленнее реальной таблицы регистра сведений. Все. Точка.

(154).2 Нет, не точка. Если в качестве результата нужно получить то, для чего используется срез последних, то мало утверждать, что запрос к реальной таблице работает быстрее. Нужно показать как это "быстрее" реализовать запросом к реальной таблице...

(155) Кому нужно? Мне не нужно :))
Кому нужно или интересно, дерзайте :))

Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Валюты", Валюта);

Запрос.Текст =
"ВЫБРАТЬ
|    КурсыВалютСрезПоследних.Валюта,
|    КурсыВалютСрезПоследних.Курс
|ИЗ
|    РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних
|ГДЕ
|    КурсыВалютСрезПоследних.Валюта В(&Валюты)";
Запрос.Выполнить();
// 0,006249 сек

Запрос.Текст =
"ВЫБРАТЬ
|    КурсыВалютСрезПоследних.Валюта,
|    КурсыВалютСрезПоследних.Курс
|ИЗ
|    РегистрСведений.КурсыВалют.СрезПоследних(, Валюта В (&Валюты)) КАК КурсыВалютСрезПоследних";
Запрос.Выполнить();
// 0,003674 сек

Запрос.Текст =
"ВЫБРАТЬ
|    МАКСИМУМ(КурсыВалют.Период) КАК Период,
|    КурсыВалют.Валюта КАК Валюта
|ПОМЕСТИТЬ ВТ_ПоследниеДатыКурсов
|ИЗ
|    РегистрСведений.КурсыВалют КАК КурсыВалют
|ГДЕ
|    КурсыВалют.Валюта В(&Валюты)
|
|СГРУППИРОВАТЬ ПО
|    КурсыВалют.Валюта
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    КурсыВалют.Валюта,
|    КурсыВалют.Курс
|ИЗ
|    РегистрСведений.КурсыВалют КАК КурсыВалют
|        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ПоследниеДатыКурсов КАК ВТ_ПоследниеДатыКурсов
|        ПО КурсыВалют.Период = ВТ_ПоследниеДатыКурсов.Период
|            И КурсыВалют.Валюта = ВТ_ПоследниеДатыКурсов.Валюта";
Запрос.Выполнить();
// 0,013053 сек

Запрос.Текст =
"ВЫБРАТЬ
|    КурсыВалют.Валюта КАК Валюта,
|    МАКСИМУМ(КурсыВалют.Период) КАК Период
|ПОМЕСТИТЬ ПериодыВалют
|ИЗ
|    РегистрСведений.КурсыВалют КАК КурсыВалют
|ГДЕ
|    КурсыВалют.Валюта В(&Валюты)
|
|СГРУППИРОВАТЬ ПО
|    КурсыВалют.Валюта
|
|ИНДЕКСИРОВАТЬ ПО
|    Валюта,
|    Период
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    КурсыВалют.Период,
|    КурсыВалют.Валюта,
|    КурсыВалют.Курс
|ИЗ
|    РегистрСведений.КурсыВалют КАК КурсыВалют
|        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПериодыВалют КАК ПериодыВалют
|        ПО КурсыВалют.Период = ПериодыВалют.Период
|            И КурсыВалют.Валюта = ПериодыВалют.Валюта";
Запрос.Выполнить();
// 0,016352 сек

В регистре 919 строк
Платформа: 8.1.15.14
Сервер БД: MS SQL 2000 (SP4)

В данном конкретном случае "СрезПоследних" оказался самым скоростным.
Не понятно чего хотел потенциальный работодатель?

(157)
Интересно, а если так

ВЫБРАТЬ ПЕРВЫЕ 1
   КурсыВалют.Валюта,
   КурсыВалют.Курс
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
   КурсыВалют.Валюта = &Валюта

УПОРЯДОЧИТЬ ПО
   Период УБЫВ

?

(159) это запрос вернет не тоже самое что и в (0) какая тут оптимизация?!

(160) Глюканул.

(0) Вам как, мнение Д. Э. Кнута является авторитетным или нет?

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

Самый главный кусок вышесказанного по-русски: несвоевременная оптимизация - корень всех зол.

Оптимизировать надо только имея фактические данные о производительности. Во всех остальных случаях это не оптимизация, это мозго.бство.

(159) похоже это самое оптимальный запрос :) Проверял на файловой чуть быстрее 2 запроса в (157)

(159) 0,003264
но это справедливо для одной валюты

(162) хорошая цитата, спасибо.

(157) 919 строк - это ничто, увеличь хотя бы до 100 000.
(163) LOL :))

(154) "Я утверждаю не это, а то, что виртуальная таблица регистра сведений работает медленнее реальной таблицы регистра сведений. Все. Точка."
Охренеть. А я думал что разговор о неоптимальной работе виртуальной таблицы среза последних, а не о том, что вычисление функции медленнее тупого вывода исходных данных.
(157) Спасибо. Совпадает с моими ожиданиями.
(159),(163) Для одной валюты это быстрее всего будет, спору нет. Но в сабже нужно для списка валют.

(166) смотрел на к-с варианте, записей в таблице курсов 3900
(169) как оказалось в (159) не быстрей :(

Вот что получил:


   Запрос.Текст =
   "ВЫБРАТЬ
   |    КурсыВалютСрезПоследних.Валюта,
   |    КурсыВалютСрезПоследних.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних
   |ГДЕ
   |    КурсыВалютСрезПоследних.Валюта В(&Валюты)";
   Запрос.Выполнить();
   // 0,012822
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    КурсыВалютСрезПоследних.Валюта,
   |    КурсыВалютСрезПоследних.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют.СрезПоследних(, Валюта В (&Валюты)) КАК КурсыВалютСрезПоследних";
   Запрос.Выполнить();
   // 0,004443
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    МАКСИМУМ(КурсыВалют.Период) КАК Период,
   |    КурсыВалют.Валюта КАК Валюта
   |ПОМЕСТИТЬ ВТ_ПоследниеДатыКурсов
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В(&Валюты)
   |
   |СГРУППИРОВАТЬ ПО
   |    КурсыВалют.Валюта
   |;
   |
   |////////////////////////////////////////////////////////////////////////////////
   
   |ВЫБРАТЬ
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ПоследниеДатыКурсов КАК ВТ_ПоследниеДатыКурсов
   |        ПО КурсыВалют.Период = ВТ_ПоследниеДатыКурсов.Период
   |            И КурсыВалют.Валюта = ВТ_ПоследниеДатыКурсов.Валюта";
   Запрос.Выполнить();
   // 0,019310
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    КурсыВалют.Валюта КАК Валюта,
   |    МАКСИМУМ(КурсыВалют.Период) КАК Период
   |ПОМЕСТИТЬ ПериодыВалют
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В(&Валюты)
   |
   |СГРУППИРОВАТЬ ПО
   |    КурсыВалют.Валюта
   |
   |ИНДЕКСИРОВАТЬ ПО
   |    Валюта,
   |    Период
   |;
   |
   |////////////////////////////////////////////////////////////////////////////////
   
   |ВЫБРАТЬ
   |    КурсыВалют.Период,
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПериодыВалют КАК ПериодыВалют
   |        ПО КурсыВалют.Период = ПериодыВалют.Период
   |            И КурсыВалют.Валюта = ПериодыВалют.Валюта";
   Запрос.Выполнить();
   // 0,014724
   
   
   Запрос.Текст    = "ВЫБРАТЬ ПЕРВЫЕ 1
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В (&Валюты)
   |
   |УПОРЯДОЧИТЬ ПО
   |    КурсыВалют.Период УБЫВ";
   Запрос.Выполнить();
   // 0,006106

Правда (0) напоминает мышиную возню, но все-равно в обед делать нечего :) и для меня еще сегодня пятница :)

(166) Индексированная временная таблица тут даст только при многократном использовании. При однократном использовании для сабжевого примера вряд ли вообще отобьется хоть на каких объемах. План выполнения запроса смотреть лень, но почти уверен, что по вложенному запросу будет выполняться соединение хэшированием, что однозначно быстрее, ИМХО.

(168) не, ну для списка валют не будет работать:

   Запрос.Текст    = "ВЫБРАТЬ ПЕРВЫЕ 1
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В (&Валюты)
   |
   |УПОРЯДОЧИТЬ ПО
   |    КурсыВалют.Период УБЫВ";
   Запрос.Выполнить();

(168) вот еще вариант:

ВЫБРАТЬ
   КурсыВалют.Валюта,
   КурсыВалют.Курс
ИЗ
   РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
   (КурсыВалют.Валюта, КурсыВалют.Период) В
           (ВЫБРАТЬ
               КурсыВалют.Валюта,
               МАКСИМУМ(КурсыВалют.Период) КАК Период
           ИЗ
               РегистрСведений.КурсыВалют КАК КурсыВалют
           ГДЕ
               КурсыВалют.Валюта В (&Валюты)
           СГРУППИРОВАТЬ ПО
                       КурсыВалют.Валюта)

(168) Гм... Разница между 0,004443 и 0,006106 может быть в пределах погрешности. По-идее, не должно медленнее быть. Хотя я в этих делах не настоящий сварщик :) Большого опыта копания в планах выполнения запросов не имею.

(172) та не будет же работать запрос для списка валют с "Выбрать ПЕРВЫЕ 1", он же получает только 1 строку, так что через виртуальную таблицу с заданными параметрами самый быстрый вариант по идее.

Вот еще сделал отбор по двум валютам из той же таблицы в 3900 записей:


   "ВЫБРАТЬ
   |    КурсыВалютСрезПоследних.Валюта,
   |    КурсыВалютСрезПоследних.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют.СрезПоследних КАК КурсыВалютСрезПоследних
   |ГДЕ
   |    КурсыВалютСрезПоследних.Валюта В(&Валюты)";
   Запрос.Выполнить();
   // 0,012822 0,005847
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    КурсыВалютСрезПоследних.Валюта,
   |    КурсыВалютСрезПоследних.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют.СрезПоследних(, Валюта В (&Валюты)) КАК КурсыВалютСрезПоследних";
   Запрос.Выполнить();
   // 0,004443 0,006225
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    МАКСИМУМ(КурсыВалют.Период) КАК Период,
   |    КурсыВалют.Валюта КАК Валюта
   |ПОМЕСТИТЬ ВТ_ПоследниеДатыКурсов
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В(&Валюты)
   |
   |СГРУППИРОВАТЬ ПО
   |    КурсыВалют.Валюта
   |;
   |
   |////////////////////////////////////////////////////////////////////////////////
   
   |ВЫБРАТЬ
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ПоследниеДатыКурсов КАК ВТ_ПоследниеДатыКурсов
   |        ПО КурсыВалют.Период = ВТ_ПоследниеДатыКурсов.Период
   |            И КурсыВалют.Валюта = ВТ_ПоследниеДатыКурсов.Валюта";
   Запрос.Выполнить();
   // 0,019310 0,016802
   
   
   Запрос.Текст =
   "ВЫБРАТЬ
   |    КурсыВалют.Валюта КАК Валюта,
   |    МАКСИМУМ(КурсыВалют.Период) КАК Период
   |ПОМЕСТИТЬ ПериодыВалют
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В(&Валюты)
   |
   |СГРУППИРОВАТЬ ПО
   |    КурсыВалют.Валюта
   |
   |ИНДЕКСИРОВАТЬ ПО
   |    Валюта,
   |    Период
   |;
   |
   |////////////////////////////////////////////////////////////////////////////////
   
   |ВЫБРАТЬ
   |    КурсыВалют.Период,
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ПериодыВалют КАК ПериодыВалют
   |        ПО КурсыВалют.Период = ПериодыВалют.Период
   |            И КурсыВалют.Валюта = ПериодыВалют.Валюта";
   Запрос.Выполнить();
   // 0,014724 0,021979
   
   
   Запрос.Текст    = "ВЫБРАТЬ ПЕРВЫЕ 1
   |    КурсыВалют.Валюта,
   |    КурсыВалют.Курс
   |ИЗ
   |    РегистрСведений.КурсыВалют КАК КурсыВалют
   |ГДЕ
   |    КурсыВалют.Валюта В (&Валюты)
   |
   |УПОРЯДОЧИТЬ ПО
   |    КурсыВалют.Период УБЫВ";
   Запрос.Выполнить();
   // 0,006106 0,002842
   
   Запрос.Текст    = "ВЫБРАТЬ
                     |    КурсыВалют.Валюта,
                     |    КурсыВалют.Курс
                     |ИЗ
                     |    РегистрСведений.КурсыВалют КАК КурсыВалют
                     |ГДЕ
                     |    (КурсыВалют.Валюта, КурсыВалют.Период) В
                     |            (ВЫБРАТЬ
                     |                КурсыВалют.Валюта,
                     |                МАКСИМУМ(КурсыВалют.Период) КАК Период
                     |            ИЗ
                     |                РегистрСведений.КурсыВалют КАК КурсыВалют
                     |            ГДЕ
                     |                КурсыВалют.Валюта В (&Валюты)
                     |            СГРУППИРОВАТЬ ПО
                     |                        КурсыВалют.Валюта)";
   Запрос.Выполнить();
   // 0,021986

Обед закончился и мышиной возне пришел капут :)


P.S.: Мне кажется на такие задачи можно отвечать только встречным вопросом, даже в задачах на специалист такого бреда не найдешь!

Ну а что в итоге-то? Почему (0) получил "неуд"?

(173) Я знаю. И если бы ты читал ветку, то знал бы, что я знаю.
(175) В том-то и дело. Все недоумевают.

(175) В итоге работодатель уже в самом начале знал какую оценку дать.

(177) а смысл, можно и по другой причине отказать...
К тому же, задача была не единственная.

(178) Кстати да. Если по первой задаче велик шанс ошибки оценки её работодателем, то вторая задачка явно поинтереснее. Но экспериментировать лень :)
В жизни мне бы в голову не пришло оптимизировать этот запрос, если бы явно не упёрся в него как в узкое место. Правильный ответ лично мне очень интересен. Кидайте варианты, а AndreYAN в следующий обед сравнит :)

(179) Ну если только через 2 недели. Это у меня сегодня пятничное настроение.

(180) Не горит :)

В (58) имеются в виду именно "реквизиты" или все-таки "измерения"?