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

Он естественно вернется пустым. Если убрать второе условие - "Номенклатура.Ссылка В ИЕРАРХИИ(&ГруппаНоменклатуры)" он отработает моментально, а если не убирать есть задержка (скорость не замерял, чисто визуальное наблюдение в консоли заросов). Как SQL разбирает условия? Как сделать оптимальнее?

использовать построитель запроса или "заглушки" в тексте запроса и СтрЗаменить, если использование построителя невозможно. есть еще объект встроенного языка "СхемаЗапроса", но он неудобный.

условия И отрабатывают все
В всегда тормоз

(2) Это точно? Где можно почитать?

для условия в ИЕРАРХИИ сервер 1с делает временную таблицу.
вот на нее время и уходит

сам скл сервер конечно же умеет короткие логические выражения вычислять

(2) нет

(4) да

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

(6) до первого Ложь, а потом прерывает?

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

(9) нет, у него анализатор есть, если условие всегда ложно, то он ничего не будет делать. в файловой анализатор тупой, хз, как он работает. в случае (0) проблема в (4)

(11) это я из логики ошибся, ИЛИ проверяются все

(0) Понятия ИЕРАРХИИ в SQL не существует, по этому это решается другими способами типа IN ( скорее всего из ранее подготовленный временной таблицы. По этому есть задержка

(14) Да, это видимо сервер 1С готовит ее не зависимо от прочих условий

(13)нет

(15) он ее не готовит, он переводит текст с одного языка запросов в другой

(17) Ну да

(18) а дальше ответ в (12)

База не файловая?

Думаю, В ИЕРАРХИИ в 1С написан более оптимально, чем можно самостоятельно его же сделать кодом или запросами.

Хотя, как вариант, можно сделать регистр сведений с измерениями 1.РодительГруппа 2.Ссылка и каким-то образом записывать данные в него (например, ПриЗаписи элемента справочника).   Но это уже какие-то извращения. Но я бы так не делал.

(21) зачем думать если можно знать? 1с сделала неплохо в целом, но часто опираясь на знания особенностей для конкретной реализации можно сделать значительно лучше

>Думаю, В ИЕРАРХИИ в 1С написан более оптимально, чем можно самостоятельно его же сделать кодом или запросами.

нет, можно перейти на nested sets. ну, или на materialized path. и тогда аналог "в иерархии" будет работать ощутимо быстрее и его можно будет использовать в качестве условий соединения.
проблема в некотором замедлении записи при изменении иерархии, что, в принципе, терпимо. но если б была нативная поддержка платформой, то вместо своих РС и кучи записи в цикле могло бы быть всего по паре запросов типа update.

(22) и как?

(23) А как быть с распределенными базами данных, когда сначала приезжает подчиненный элемент с указанием битой ссылки на родителя, а родитель после этого только грузится?

(25) и что?

(24) повторяю "опираясь на знания особенностей для конкретной реализации"

(26) "nested sets" или "materialized path" - это какие-то отдельные таблицы/поля? или они как-то динамически вычисляются? Если поля, тогда при записи элемента справочника может быть неизвестен его родитель (при загрузке по РБД).

(28) вы про план выполнения запроса покурите для начала.

(28) ты же прочитал, что такое nested sets и materialized path? проблемы с РИБ могут быть только в случае nested sets, да и то они решаемы.

(1) СхемаЗапроса отличный инструмент, но нужно уметь его готовить

(0) http://catalog.mista.ru/public/940250/

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

если вычисление первого условия занимает очень мало времени, то можно сделать что-то вроде такого:
[code]
ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    &Параметр1
    И ВЫБОР
            КОГДА &Параметр1
                ТОГДА Номенклатура.Ссылка В ИЕРАРХИИ (&ГруппаНоменклатуры)
            ИНАЧЕ ИСТИНА
        КОНЕЦ
[code]

а лучше так

ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    ВЫБОР
            КОГДА &Параметр1
                ТОГДА Номенклатура.Ссылка В ИЕРАРХИИ (&ГруппаНоменклатуры)
            ИНАЧЕ ЛОЖЬ
        КОНЕЦ

(33) у мс-скл порядка 80 правил ускоряющих выполнение запроса... Скорее поверю что ТС ошибся

(0) В ИЕРАРХИИ убрать нужно

(35) Фу...

(38) какие Ваши предложения?

(39) пока наблюдать

(39) Плохо когда у тебя в секции ГДЕ есть еще и ВЫБОР КОГДА...

(41) чем именно это плохо? Интересуюсь не из праздного любопытства, а чтобы знания подтянуть.

Вообще, эта конструкция позволяет избежать проверки обоих условий в случае, если первое не выполняется. А ситуация из (0) действительно имеет место быть, я запрос ТСа в консоли с замером прогонял, - 0,8с выполняется. Мой в случае &Параметр1=Ложь выполняется мгновенно.

(35) Да, этот мгновенно отрабатывает. Присоединяюсь к вопросу к (41), чем это плохо?

(43) А если передавать В ИЕРАРХИИ пустую ссылку, разве будет долго отрабатывать?

(44) ещё раз замерил запрос из (0):

- при передаче группы номенклатуры отработал в среднем за 0,4 сек
- при передаче пустой ссылки отработал в среднем за 1,2 сек

(42) (43) Если я не ошибаюсь, то в случае ВЫБОР КОГДА в секции ГДЕ, оптимизатор может ошибаться с выбором плана запросов...
Поправьте меня, если не прав

(46) Не прав. В секции ГДЕ определяется вариант поиска данных в индексах или куче. Вариант с ВЫБОР КОГДА не использует индекс ни при каких условиях. Ну а плохо это или не очень зависит от запроса, селективности условия и наличия индекса в принципе.
Обычно такое условие потенциальная ошибка. Но не по причине ошибки оптимизатора, просто он так работает.

(47) 1С достаточно умен, чтобы ВЫБОР в ГДЕ транслировать в нормальный SQL запрос, если там условие не завязано на значение поля таблицы.

Так нельзя:

ГДЕ
    ВЫБОР
            КОГДА Номенклатура.Код=&Код
                ТОГДА Номенклатура.Код = &Код
            ИНАЧЕ ИСТИНА
        КОНЕЦ

а так можно:

ГДЕ
    ВЫБОР
            КОГДА &ОтбиратьПоКоду
                ТОГДА Номенклатура.Код = &Код
            ИНАЧЕ ИСТИНА
        КОНЕЦ

(49) Ваша правда. Проверил профайлером.
В любом случае стоит себя отучать от вычислений над индексированными полями

(50) Надо отучать мыслить догмами. Индексировать ВТ, всегда помещать отбор в параметры вирттаб, не использовать в ГДЕ ВЫБОР. Вот это всё.

(48),(49) Спасибо за объяснение