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

Легко меняется на
НЕ Сотрудник.ВидЗанятости В (&ВнутреннееСовместительство)

(0) ты косяк

успокойся, надо же им на ком то тренироваться

(0) ща набигут знающие люди с профайлерами на перевес и окажется что франч то умный а ты зеленый сопляк ЖКК не нюхавший..

(0) в файловой базе их код будет в 66 раз быстрее твоего.

(0) У месье на сантиметр больше?

(1) (3) (4) (5) Поясните, плиз, особенно про 66

про (4) я тоже не верю. С хрена ли?

Ты просто гений достоин зарплаты 200к

(0) Я бы сначала спросил почему реализованно именно так, а не как у тебя

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

(0) пнх

(0) уволить за неявный join

(0) А вот скажи, что будет быстрее:


ГДЕ
    ПроданныеТовары.Ссылка.Дата МЕЖДУ &ДатаНачалаЧекККМ И &ДатаОкончанияЧекККМ
    И ПроданныеТовары.Ссылка.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Пробит)
    И ПроданныеТовары.Ссылка.КассоваяСмена.СтатусКассовойСмены <> ЗНАЧЕНИЕ(Перечисление.СтатусыКассовойСмены.ЗакрытаЧекиЗаархивированы)
    И ПроданныеТовары.Ссылка.Партнер = &Партнер
    И ПроданныеТовары.Ссылка.Партнер <> ЗНАЧЕНИЕ(Справочник.Партнеры.РозничныйПокупатель)


или


ГДЕ
    ПроданныеТовары.Ссылка В (
        ВЫБРАТЬ
            Т.Ссылка
        ИЗ
            Документ.ЧекККМ КАК Т
        ГДЕ
            Т.Дата МЕЖДУ &ДатаНачалаЧекККМ И &ДатаОкончанияЧекККМ
            И Т.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Пробит)
            И Т.КассоваяСмена.СтатусКассовойСмены = ЗНАЧЕНИЕ(Перечисление.СтатусыКассовойСмены.Открыта)
            И Т.Партнер = &Партнер
            И Т.Партнер <> ЗНАЧЕНИЕ(Справочник.Партнеры.РозничныйПокупатель)
)


И почему. И сможешь ли ты это определить без отладчика/профайлера

(3) ^^^ а ты сможешь ответить на этот вопрос?

(14) в 12 же ответили уже

(0)
Брюки превращаются, превращаются брюки, в элегантные шорты...

ГДЕ
    СотрудникиОрганизаций.ВидЗанятости <> ЗНАЧЕНИЕ(Перечисление.ВидыЗанятостиВОрганизации.ВнутреннееСовместительство)


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

+17 когда гораздо больше получается

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

скучно, уныло, банально, тело сисек не раскрыто
автор, стена там >>

(15) Что ответили в (12)? Во-первых необосновано, а во-вторых к моему случаю ещё и не относиться. Так как неявный джойн получается в обоих запросах.

(19) Почти угадал. Только через точку тоже получается одна таблица - табличная часть документа ЧекККМ. Но проблема в другом. В первом случае у платформы не получается использовать комбинацию индексов, в результате сначала выбирает по первичному индексу - по дате, а потом фуллсканом фильтрует по остальным условиям. А если в периоде десяток тысяч документов, то получается очень долго.

Во втором случае индексы используются по полной программе - не только дата, но и статус, партнёр и т.п. В результате время выполнения запроса пара секунд вместо ~5 минут. А так как этот код выполняется в момент расчета скидки по чеку, то время было очень критично.

Куски кода, кстати, из типовой УТ11. Первый из 11.0.9, второй из какой-то из последних, типа 11.1.2

+(21) в слове "относиться" мягкий знак прошу не читать.

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

(21) я предположил что Ссылка может быть не только документом ЧекККМ, но и еще каким-нибудь. Поэтому и написал что может быть соединение не только с одной таблицей