Подскажите, все ли здесь правильно?

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

нет

5 ошибок насчитал

(2) а две последние строчки - это у тебя две ошибки или одна?

Сообщите пожалуйста об ошибках. Это крайне важно. Я нашел ошибки некоторые, необходимо сравнить.

(4)
ГДЕ
    ТоварыНаСкладахОстатки.Склад = &Склад
    И ТоварыОрганизацийОстатки.Организация = &Организация
    И ТоварыНаСкладахОстатки.Номенклатура = &Номенклатура

это одна большая ошибка

(4) сначала ты свои выкладывай, а то так не интересно

(4) Да легко
После сообщите запятая нужна

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

(8) Потому что товары организаций там нет складов. А в товарах на склаждах нет организаций, это разные разделы учета

(8) слона-то ты и не приметил.
Соединение здесь само по себе - это один большой косяк. Виртуальные таблицы соединяют друг с другом только мудаки.

ТоварыНаСкладахОстатки.Номенклатура = ТоварыОрганизацийОстатки.Номенклатура.Ссылка Само по себе грубейшая ошибка, а если взять последнюю УТ, то в товарах организации нет измерения Номенклатура вообще, там ключиАналитикиНоменклатуры

(10) +100!

(3) Считал как две. Там с учетом отбора по номенклатуре можно ещё одну прибавить, но уже было лень писать)

(8) Соед...

(10) Это оперативные остатки, там это допускается

(9) это почему нет склада в товарах организаций? от настроек зависит.

и отборы все - в параметры надо. Это помимо того, что так в принципе не надо делать вообще изначально

(15) Потому что нету https://ibb.co/dZ7iGV

(10) А что не так с соединением виртуальных таблиц?
Как иначе получить остатки из двух виртуальных таблиц в строке?

(17) Конфигурация УПП 1.3, забыл сказать.

(18) При неоперативных остатках это подзапрос 2го уровня вложенности и оптимизатор СУБД очень сильно лажает. Это если в кратце.
При оперативных отстатках - просто поиск с отборами в таблице остатков - там соединение 2х вирт таблиц остатков не вызовет технологических проблем

(18) для этого - временные таблицы.
С самими виртуальными нет проблем, проблемы начинаются с из соединением друг с другом потому, что виртуальная таблица - это запрос.

(20) Т.е. просто сначала в ВТ предлагаете поместить?

(21) Не просто запрос, а получаются расчитанные остатки и от них суммируются движения, и при соединении оптимизатор очень часто и очень сильно лажает.
При ОПЕРАТИВНЫХ остатках (без указания периода остатков) - простейший запрос.
ВТ тоже не бесплатные.
Оперативные остатки - не имеет смысла.
Не оперативные остатки - имеет смысл

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

(23) горшочек, не вари

(22) да

(25) Ну ок, мне же лучше, я потом за исправление в том числе таких ошибок премии получаю.

(22) не обязательно, все зависит от размера выборки виртуальных таблиц после того как сделаешь (24)

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

Можете поставить оценку по пятибалльной шкале разработчику данного запроса?

(28) кол. Вазелинового дерева.

(28) 2, все ошибки, кроме трений нужно ВТ или нет являются грубейшими

И хоть никто не обратил на это внимание, но вот это ТоварыОрганизацийОстатки.Номенклатура.Ссылка Просто злейшее зло, особенно в соединении

(28) данный запрос на базе где в регистрах будет хотя бы по 100тыс записей (а это очень не много) - тебе завесит сервак минут на 10... причем полность....

по этому автору - 2 с минусом

(32) Не, может и проскочить, я встречал когда и 3 соединения ВТ, где параметры были в ГДЕ оптимизатор понимал и подбирал оптимальный план запроса, но это исключение, а не правило.

(31) полно-те вам, батенька, брюзжать - на это обратил внимание автор

(31) это не всегда ошибка, это будет гемороем только если тип составной, остальное скуль заоптимизирует с большой долей вероятности.

вообще условие в джойне не должно вести к деградации составного индекса, ТоварыОрганизацийОстатки.Номенклатура.Ссылка - однозначно ведет к деградации, но тут вопрос на какой длине это будет, если это условие отсечет только хвост индекса, то все не так и плохо, а вот если приведет к полному фулскану - то плохо...

(34) Лучи добра Вам)

(33) эо просто оптимизатор ошибся четное количество раз

мучительно нудная вечеринка в кнайпе "Старые пердуны" объявляется открытой...

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

(39) Да будет, но не двойной

(14) Соединение количественных данных вместо объединения - верный путь получить неверные цифры из-за задваивания-затраивания строк.

(32) Проверил на базе объемом 300 Гб. Отработал за секунду. Причем это на тестовом сервере, где оборудование уже не фонтан.

(28) 2 балла разарбочику

(42) 1) а смысл смотреть без нагрузки.
2) соединение по 1 номенклатуре из оперативных остатков 1 секунду - это просто ужасный результат.

Кто-то тут курсов по оптимизации похоже пересмотрел. Только смотрел похоже в режиме 5 минут через 10.


Первый вопрос к запросу - а что хотели получить. А уж потом про ошибки.

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

(44) Это компенсируется тем, что база не в ОЗУ, и лежит на "зеленом" HDD WD. Ну и обещали 10 минут минимум. При этом если бы оптимизатор лажанул, то запрос минимум 30 секунд бы работал на этой базе.

(2) я насчитал одну ошибку. Весь запрос - одна большая ошибка.

(0) для начала надо узнать : какую задачу решал поставленный запрос

Например, если есть ордерная схема, то запрос все эти движения без подтверждений не учитываются

(49) 100% это тестовая задача - найдите ошибки в этом запросе и объясните почему это так

(50) по мне главное это понимание как работают те или регистры

Остальное дело техники

(0) По моему, тут даже не в запросе что-то не так. Тут с архитектурой беда. Два регистра с остатками ТМЦ - это злейшее зло. Я то думал, после ТИСа они так больше не лепят, ан оказывается нет...

(52) А у тебя были сомнения, что в 1с сидят качественные архитекторы?

(51) то что при соединении все поплывет это ответ на должность повыше, обычно просят не вдаваться в детали, а рассказать что в тексте не нравится сходу.
(53) ну ДО то адекватный достаточно вышел.

(53) ну, местами то вполне ничо
но вот последнее время частенько в ЗиКе колупаюсь - вот где наркоманы то тусовались. да и в ЗУПе тоже.  традиции блин...

вот всё написали же, чего не читаем)))

https://its.1c.ru/db/metod8dev#content:5842:hdoc:vtable_join

(52) первый для хранения остатков по складам и резервам

Второй остатки для хранения склады/организации -- основание для расчета себеса

(50) нет, это к сожалению не тест, это в жизни.