Всем привет!
Тут на выходных дали задачку по УТ 10.3 разобраться что не так с запросом и как его можно переделать)))
Выполняется в консоли все.
Текст запроса:

ВЫБРАТЬ
	ЗначенияСвойствОбъектов.Значение КАК ВидТовара,
	ПродажиОбороты.Номенклатура КАК Номенклатура,
	СУММА(ПродажиОбороты.СтоимостьОборот) КАК Сумма
ИЗ
	РегистрНакопления.Продажи.Обороты(&ДатаНачала, &ДатаОкончания, , ) КАК ПродажиОбороты
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
		ПО ПродажиОбороты.Номенклатура = ЗначенияСвойствОбъектов.Объект
ГДЕ
	ЗначенияСвойствОбъектов.Свойство.Код = "000000978"

СГРУППИРОВАТЬ ПО
	ПродажиОбороты.Номенклатура,
	ЗначенияСвойствОбъектов.Значение

УПОРЯДОЧИТЬ ПО
	ВидТовара,
	Номенклатура
ИТОГИ
	СУММА(Сумма)
ПО
	ВидТовара

Свойство.Код = блабла, это оч плохо (ваще говонкод) тут или конкретное значение сврйства передать надо или Варазить, если Свойство составное

Я бы сначала получил всё что нужно из РегистрСведений.ЗначенияСвойствОбъектов.

Потом наложил фильтр внутри Продажи.Обороты(

(0) ГДЕ заменить на И.
Сгруппировать вообще убрать

(1) Там просто одно свойство нужно, убрать в параметры тоже думаю.
(2) Интересно.
Если массив номенклатуры может получиться очень большой, а продаж всего 3 позиции, то в чем логика?
(3)Спасибо! Это увидел

(3) там не внутреннее соединение,тс же фильтровать надо вроде

(0) Давайте по порядку:
1) Нельзя делать соединение с виртуальными таблицами. см. ( https://its.1c.ru/db/metod8dev/content/5842/hdoc ). Поэтому результат запроса к виртуальной таблице лучше поместить во временную таблицу.
2) Выборка с регистра сведений ЗначенияСвойствОбъектов производится по всем значениям и только потом накладывается отбор, необходимо сделать предварительную выборку с использованием фильтра по номенклатуре из временной таблицы пункта 1 и свойства. Причем фильтр по свойству должен быть без разыменования. Т.е. ЗначенияСвойствОбъектов.Свойство.Код - это некорректное решение, передавайте параметр.
3) При левом соединении обязательно указание ЕстьNULL() для полей соединяемых таблиц. Т.е. ЗначенияСвойствОбъектов.Значение КАК ВидТовара - это некорректно.
4) Группировка лишняя, так как выбираются уникальные значения.

Это только навскидку.

(6) 3. не нужно есть нулл т.к. по правой таблице условие в где, а значит соединение превращается во внутреннее.
1,2 согласен

я щЕтаю, что Свойство.Код = блабла можно использовать - ничего такого тут нет

(8) привет. я того же мнения. коллега.

(6) 1 - Так нельзя же если виртуальная таблица справа. Если виртуальная таблица слева, то можно.

(8) (9) Ваше мнение неавторитетно, потому что вы глупые. Использование кодов элементов в программном коде — это моветон. Лучше сделать элемент предопределённым.

(11) моё мнение как раз таки авторитетно, я — гуру.

(11) Возможно стоит определиться с целями. Делать предопределенные под каждый запрос в консоли не меньший моветон.

(13) полностью согласен, коллега.

Истина как всегда посередине. Есзи запрос для внешнего отчёта, одного из сотен, например только по учёту котов на забалансе для ловли мышей, то вполне можно
Код = "000000978"
Если нужна только позиция "Кот домашний средней пушистости".

Я бы не заморачивался с альтернативой «переключения выборки» в конструкции:

Выбор когда тогда…

Сам применяю, но не особо часто

Более того, я с недавних пор переключился на пост обработку табличного документа скд после вывода в него данных

Это позволило увеличить скорость работы в некоторых случаях до 1000 раз!

(11) не возражаю…

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

(19) Я это правило не по стандартам учил, жизнь в свое время заставила... Когда у тебя работавший годами запрос вдруг начинает тормозить, причём обновление статистики на время "лечит" проблему, а потом снова необъяснимые тормоза. И тратишь не один час в профайлере, чтобы понять почему был выбран не оптимальный план запроса, волей неволе начинаешь писать запросы по другому. Дело каждого конечно если у вас микробаза и все работает - то оставляйте, а я лучше перестрахуюсь.

(11) Некоторые деятели поступают ещё круче, привязываясь к наименованию.

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

(17) Станиславский бы тебе сказал - не верю. И я вместе с ним.

ИЗ
    РегистрНакопления.Продажи.Обороты(&ДатаНачала, &ДатаОкончания, , ) КАК ПродажиОбороты
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
        ПО ПродажиОбороты.Номенклатура = ЗначенияСвойствОбъектов.Объект
ГДЕ
    ЗначенияСвойствОбъектов.Свойство.Код = "000000978"

Оптимизатор разве это не превращает во вн соединение?

Я тому что, зачем отдельная выбора РС ЗначенияСвойствОбъектов

(24) превращает "В/IN (тут очень много всего)", тут мимо

(0) уже 4 года не открывал конфигуратор, но вроде как помимо (6), еще важно смотреть - какой обычно период устанавливают.
кроме того, чтобы удостовериться после переписывания, можно глянуть во что такой запрос в технологическом журнале превращается.
и далее уже смотреть средствами СУБД, explain analyze и тому подобное.

(27) кто знает такие ругательства как ТЖ и "тому подобное" не задает вопросов как в (0)... ))))

(28) это да, когда 1Сником был, я был типа ведущим разработчиком.
собес на доработку нетиповой конфигурации, которую я разрабатывал с чуваками, по-моему, осилил только Hedgehog.
но это было давно и неправда.
а сейчас я просто сеньор на другом языке программирования.

(0) "ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
        ПО ПродажиОбороты.Номенклатура = ЗначенияСвойствОбъектов.Объект"
-------------------------
1) ЗначенияСвойствОбъектов.Объект - обычно имеет составной тип, редко меньше десяти разновидностей. То есть тут вы соединяете минимум с десятью разными таблицами
-------------------------
2) Отбор по номенклатуре лучше накладывать в параметрах виртуальной таблицы

(30) Эту ерунду нейросетка что ли написала?

(29) на каком стеке сейчас кодишь?

(32) Golang

(0)
"Тут на выходных дали задачку по УТ 10.3 "

Добрались до очного собеседования?

Задача не сложная вроде как.

(34) Так вот и запнулся потому что вроде не сложная, ищу подводные камни))

Сделал так:

 ВЫБРАТЬ
	ПродажиОбороты.Номенклатура КАК Номенклатура,
	ПродажиОбороты.СтоимостьОборот КАК Сумма
ПОМЕСТИТЬ Продажи
ИЗ
	РегистрНакопления.Продажи.Обороты(&ДатаНачала, &ДатаОкончания, , ) КАК ПродажиОбороты
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	ЗначенияСвойствОбъектов.Значение КАК ВидТовара,
	Продажи.Номенклатура,
	Продажи.Сумма КАК Сумма
ИЗ
	Продажи КАК Продажи
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
		ПО Продажи.Номенклатура = ЗначенияСвойствОбъектов.Объект
	   И (ЗначенияСвойствОбъектов.Свойство.Код = "000000978")

УПОРЯДОЧИТЬ ПО
	ВидТовара
ИТОГИ
	СУММА(Сумма)
ПО
	ОБЩИЕ,
	ВидТовара 

(35) можно конечно, отбор по ЗначенияСвойствОбъектов из таб продаж сделать, но что это даст?

Я бы сделал что-то типа такого. Варианты отличаются использованием разных источников данных.

Вариант 1. С виртуальной таблицей оборотов.
Возможно использование отбора в параметрах виртуальной таблицы оборотов избыточно.

ВЫБРАТЬ
 ЗначенияСвойствОбъектов.Объект КАК Номенклатура,
 ЗначенияСвойствОбъектов.Значение КАК ВидТовара
ПОМЕСТИТЬ ВТ_Номенклатура
ИЗ
 РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
ГДЕ
 ЗначенияСвойствОбъектов.Свойство.Код = "000000978"
   И ЗначенияСвойствОбъектов.Объект ССЫЛКА Справочник.Номенклатура
ИНДЕКСИРОВАТЬ ПО
 Номенклатура УНИКАЛЬНО
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
 ВТ_Номенклатура.ВидТовара КАК ВидТовара,
 ПродажиОбороты.Номенклатура КАК Номенклатура,
 ПродажиОбороты.СтоимостьОборот КАК Сумма
ИЗ
 РегистрНакопления.Продажи.Обороты(&ДатаНачала, &ДатаОкончания,
	  ,
	  Номенклатура В
		 (ВЫБРАТЬ
		   ВТ_Номенклатура.Номенклатура
		  ИЗ
		   ВТ_Номенклатура КАК ВТ_Номенклатура)) КАК ПродажиОбороты
   ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_Номенклатура КАК ВТ_Номенклатура
	 ПО ПродажиОбороты.Номенклатура = ВТ_Номенклатура.Номенклатура
УПОРЯДОЧИТЬ ПО
 ВидТовара,
 Номенклатура
ИТОГИ
 СУММА(Сумма)
ПО
 ВидТовара

Вариант 2. С первичной таблицей движений регистра. Иногда такие варианты работают быстрее виртуальных таблиц.

ВЫБРАТЬ
 ЗначенияСвойствОбъектов.Объект КАК Номенклатура,
 ЗначенияСвойствОбъектов.Значение КАК ВидТовара
ПОМЕСТИТЬ ВТ_Номенклатура
ИЗ
 РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
ГДЕ
 ЗначенияСвойствОбъектов.Свойство.Код = "000000978"
  И ЗначенияСвойствОбъектов.Объект ССЫЛКА Справочник.Номенклатура
ИНДЕКСИРОВАТЬ ПО
  Номенклатура УНИКАЛЬНО
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
 ВТ_Номенклатура.ВидТовара КАК ВидТовара,
 Продажи.Номенклатура КАК Номенклатура,
 СУММА(Продажи.Стоимость) КАК Сумма
ИЗ
 РегистрНакопления.Продажи КАК Продажи
   ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_Номенклатура КАК ВТ_Номенклатура
	ПО Продажи.Номенклатура = ВТ_Номенклатура.Номенклатура
ГДЕ
 Продажи.Период МЕЖДУ (&ДатаНачала, &ДатаОкончания)
   И Продажи.Активность
СГРУППИРОВАТЬ ПО
 Продажи.Номенклатура,
 ВТ_Номенклатура.ВидТовара
УПОРЯДОЧИТЬ ПО
 ВидТовара,
 Номенклатура
ИТОГИ
 СУММА(Сумма)
ПО
 ВидТовара

имхо сначала обороты в отдельную таблицу
потом значения свойств внутренним соединением к таблице продаж по номенклатуре, и так же во временную таблицу
и третий продажи -> свойства.
и да, код не надо запрашивать, нужна ссылка, как она достается не так принципиально.
типа сначала уменьшаем два множества до минимума, а потом работаем с ними, вместо того чтобы читать всю таблицу свойств в левом соединении.
но вообще нужон explain analyze, без него это вилами по воде.

(37) Спасибо!
Второй вариант мне тоже больше нравится.
(38) Хммм... Три выборки быстрее будет?

(39) Дело не в количестве выборок, а в фильтрах, индексах, объёмах данных. Иногда 10 выборок быстрее одной

(40) про индексы и фильтры согласен.
Но в (38) объём данных разве будет разный?
В чем принципиальное отличие помещения двух таблиц в третью и наложение фильтра по итогу, и выборки сразу с фильтром?

Ушел учить матчасть

(41) Объём данных зависит от реальной базы данных и плана запроса. Выборка к таблице с 100 записей и 100 млн записей отличается принципиально

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

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

А расчёты при выборке из виртуальной таблицы тоже тормозят выполнение? Например расчет скидки при выборке из таблицы продаж.
Лучше сделать выборку данных поместить во временную и потом сделать все расчёты?

(45)
Снимаецо вопрос)))
Почему это может быть медленно:
Повторные вычисления: Если расчеты выполняются для каждой строки, это может привести к дублированию вычислений, особенно если они сложные.

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

Параллелизм: Некоторые СУБД могут не оптимизировать параллельное выполнение сложных расчетов в виртуальных таблицах.

Когда использовать временные таблицы:
Использование временных таблиц может быть полезным в следующих случаях:

Сложные расчеты: Если расчеты требуют значительных ресурсов, их можно выполнить один раз и сохранить результаты во временной таблице.

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

Упрощение запросов: Временные таблицы могут сделать запросы более читаемыми и управляемыми.

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

(47) Ага. Страшно представить что на втором уровне))

(47) А насколько оптимально нейронки строят запросы?
Используете их в работе?

(31)Он все правильно написал. Если поле составное(а оно составное), то будет столько джоинов сколько типов. Нужно или самому написать джоин или выразить. Но вот такие выражения "ЗначенияСвойствОбъектов.Свойство.Код" для составных типов могут легко увеличить время выполнения запроса в тысячи раз на ровном месте.

(50) "ЗначенияСвойствОбъектов.Свойство.Код" для составных типов могут легко увеличить время выполнения запроса в тысячи раз на ровном месте.
Кроме передачи параметра какие варианты есть?

Хватит разврата