Вопрос по производительности работы типовой конфигурации:
есть РН Расходы УСН, у которого есть измерение составного типа Партия (документы)
в модуле проведения документа есть запрос, где получаются остатки по этому РН по определенным условиям и далее они сортируются по полю Партия.Дата.

Естественно SQL делает соединения с таблицами всех типов документов, которые установлены для этого поля.
Вопрос - можно как-то оптимизировать выполнение этого запроса?

Единственный вариант, который знаю, это уменьшить кол-во типов документов для этого поля до реально используемых. Но это очень грубо.

ещё куеву тучу ВЫРАЗИТЬ можно написать
Когда ТИПЗНАЧЕНИЯ(Пратия) = ТИП("Документа.АляУлю") Тогда

(1) ВЫРАЗИТЬ надо писать однозначно когда работаешь с полями составного типа, иначе запрос будет коннектить все таблицы, на которые ссылается поле составного типа.

(0) Нет.

(2) я вкурсе, (0) перечитай внимательно - в типовых не делают этого

Ситуацию отлично можно передать словами:

Когда-нибудь мы вспомним это
И не поверится самим
А нынче нам нужна одна победа
Одна на всех мы за ценой не постоим
Одна на всех мы за ценой не постоим

Когда нибудь введут в базу новый тип документа, которого нет в списке текуших, либо в Партию впилят свой, особый партионный документ и тогда - оля, улю, приплыли.

Зависит от условий

(6) тогда можно как в 7.7 сделать - справочник Партий, у которого будут все нужные для запроса реквизиты и ссылка на документ

а вот в семерке был справочник партий...

(8) Я смутно это помню, но как по мне - страшная херовина была

(1) сомневаюсь что такой вариант будет быстрее работать на кол-ве документов в типе Партия больше 30

да, для оптимизации справочник - вещь конечно в этом смысле

Для начала - оптимизировать для чего? Для вашей базы на текущий момент это проблема?
+
Что за запрос (типовой или ваш), какие условия накладываются?

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

(11) не будет "соединения с таблицами всех типов документов" зато... я то сам против чесно говоря

(14) Здесь тип уже составной. Хотя это отдельный вопрос - нет ли там пустых ссылок вместо неопределено :)

(16) в РБ кстати норм сделали, если субконто составного типа то в модуле регистра принудительно неопределено ставили, чтоб случайно не случился разрыв по субконто, если пустую ссылку фиганут

(17) 1с заботится о прогерах как только может

(18) ага, сначала расставляет грабли - потом мужественно их же собирает ))

(18) скорее о психике бухгалтеров, когда они в оборотке увидят разрывы по Пустым полям

(19) Это естественный отбор совсем нежизнеспособных дятлов.

(0) Соединение какбе будет и так только с реально используемыми таблицами.

(22) профайлер говорит обратное

Это у тебя еще по божески. Вот у кривых рук некой организации был тип значения у ПВХ - документ ссылка.

А запрос был такой
"ВЫБРАТЬ *
ИЗ РегистрСведений.Такойто
ГДЕ Измерение = ПВХ.Такойто
И Ресурс.Проведен"

Ой после такого запроса как в КА висло проведение любого документа, ой как висло. На 30 минут, каждый

А кодик у этих криворуких друзей был закрыт (читай без исходного модуля). По шишкам получил программист, а контора непричем, и в обратной связи через сутки после происшествия написали - "нашли ошибку, исправим в следующей версии, которая выйдет через 2 месяца"


Так что думай... :)

(22) Фигушки. Со всеми возможными - это всегда при обращении через точку.

(0) Добавить измерение Дата.

(26) Ахиренно. Это пять!

соединение по кластерному индексу вообщето не дорогая операция. Если конечно таблиц не более 256

(27) и что тебе не понравилось?

(27) При необходимости жертвуйте компактностью хранения данных ради производительности. Если в запросе вам понадобилось значение, полученное через ссылку, то, возможно, это значение можно хранить непосредственно в данном объекте. Например, если при работе с регистром вам требуется информация о дате регистратора, вы можете завести в регистре соответствующий реквизит и назначать ему значение при проведении документов. Это приведет к дублированию информации и некоторому (незначительному) увеличению ее объема, но может существенно повысить производительность и стабильность работы запроса.

(26) план запроса по разному строиться. У меня это Nested Loops

(30) если нужно отбор делать по дате, то конечно нужно выводить + индексы, а так смысла мало