Привет,
Есть 2 запроса:

ВЫБРАТЬ
   ЗаказКлиента.Ссылка
ИЗ Документ.ЗаказКлиента КАК ЗаказКлиента
ГДЕ ЗаказКлиента.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыЗаказовКлиентов.Закрыт)

Или такой вариант:

ВЫБРАТЬ
   ЗаказКлиента.Ссылка
ИЗ Документ.ЗаказКлиента КАК ЗаказКлиента
ГДЕ ЗаказКлиента.Статус = &Закрыт

и передача параметра &Закрыт в запрос.

В документации не нашел ответа на следующий вопрос:
В случае использования конструкции ЗНАЧЕНИЕ() в запросе, будет ли для каждой строки таблицы ЗаказКлиента происходить запрос к перечислению, или оно умное и получит значение перечисления всего 1 раз? Как в случае с передачей значения перечисления в запрос по параметру. Или это абсолютно одинаковые вещи?

Значение это не функция, а способ получения константы, как и ДатаВремя

(1) Ок.
Обращение к этой константе происходит N раз в первом случае и 1 раз во втором, верно?

(2) Можно посмотреть запрос, который идёт к серверу

(2) скорее, на этапе построения плана запроса.
ведь насколько я понимаю, аргумент Значения() - константа?
или я хреново понимаю?

Скорее всего параметром втыкается в текст запроса скуля.
Точно не рассчитывается для каждой строчки таблицы)

Вопрос, каким образом кэшируется(если кэшируется), и получается ли повторно, если дважды используется в тексте запроса 1С

(2) Скорее всего предопределенные кэшируются и при трансляции запроса подставляется готовый литерал. То есть вообще ни одного запроса не будет.

Сколько людей столько и мнений)

Почему корпорация 1С не документирует такие вещи? или не там ищу?

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

(7) А зачем? Может, ты ещё захочешь руками индексы создавать? И план запроса прямо в языке 1с получать?

А потом ещё update и delete в языке запросов потребуешь....

Довольно того, что есть надежда, что ЗНАЧЕНИЕ() не вычисляется 100500 раз.

(9) похвально задавать подобные вопросы, лишь бы топикстартер не разочароваться со временем от большого количества "потому что гладиолус".

Варианта два, либо передается как параметр, либо непосредственно в тексте запроса прописана константа, все остальное не логично

Как бы 1С рекомендует пользоваться значениями. Что было бы очень странно если это соединение :)

(0) Это кому как нравится, я вот предпочитаю писать через значения, там где можно, не заморачиваться с лишними параметрами :)

(2) Нет, но вы можете поспорить :)

(7) перечисление уже константа, его не меняют каждую секунду.

(0) Я за первый вариант. Пора делать голосовалку )

(0) Говорят, что в нормальных консолях есть возможность увидеть, а затем и посмотреть глазами план запроса.

P.S.
Врут, поди (с)

(19) Нет, не врут, SQL могет, а еще SQL может делать такие связки запросов, что 1С курит в сторонке.
И что бы это сделать в 1С, надо написать еще парочку десятку строчек и замедлить запрос до максимума :)

(0) (2) >> будет ли для каждой строки таблицы ЗаказКлиента происходить запрос к перечислению
давно б уже sql-запросы глянул и увидел, что они одинаковые

(20) SQL не делает связки запросов, их делает сервер 1С

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

Открыть профайлер видимо уже совсем лень

Белоусов говорит все это фантики.
Разницы нет.

План запроса к скл базе будет один и тот же.

Вопрос только предпочтений и длинны написанного кода.

Белоусов устарел. Все что можно - через значения.

(25)
не без этого.

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

насколько это критично - вопрос холливарный

(27) Да там при создании запроса к базе константу в виде значения передают, там нет подзапроса. Сами константы кэшируются, по этому использовать значение() оправдано

(27) "константы безусловно быстрее компилируют/подготавливают запрос к выполнению чем параметры"

Правда, сама 1с об этом не знает... Вот только что встретил в типовой "И ПометкаУдаления = &пометка" и передаётся безусловная ложь параметром...

(29) а насколько свежая типовая? может ее корни еще с 8.0 тянутся

(29) А вы уверены, что параметр запроса 1с транслируется в параметр запроса sql? А не подставляется в текст запроса в виде константы при трансляции?

(30) БП3 предпоследнего релиза...
А откуда там ноги растут...

(31) В данном случае не уверен, не проверял. Но обычно передаётся в скуль.

(0) Пофиг

(31) > А не подставляется в текст запроса
Уверенно не подставлется, платформщики не дураки. Все оборачивается в параметризованный sp_executesql, иначе кэшу планов запросов очень больно.

(31) Если программист задаёт параметр, то 1с и будет транслировать в параметр sql, платформа же не знает и не анализирует, будешь ли ты задавать true или false неоднократно в один и тот же запрос

(31) сильно навскидку, похоже на то, что если только примитивные типы, то литералами подставляет
WHERE (T1._Marked = 0x00) AND T1._Posted = 0x01

если ссылки, то переменными:
WHERE (T1._Marked = 0x00) AND (T1._IDRRef = P1)',N'P1 varbinary(16)',0xB8DF0050569E464711EBEBA573D03491

(37) "WHERE (T1._Marked = 0x00) AND T1._Posted = 0x01"
Это из какого 1с-запроса странслировано?

второй вариант с параметром больше нравится

отлаживать с ЗНАЧЕНИЕ() проще

(38)

выбрать первые 100 Номер
Из документ.мойдок
where пометкаудаления = &t
И Проведен

(41) Хм... А если взять не стандартный реквизит, тоже булёвый? (у меня под рукой сейчас нет серверной 1с с доступом к скулю)

(36) В момент выполнения запроса платформа однозначно знает все параметры, которые были переданы запросу. И может строить запрос с учетом этого знания.

(42) аналогично:
WHERE (T1._Marked = 0x00) AND (T1._Fld2792 = 0x00) AND T1._Posted = 0x01

(44) Забавно...

(43) В момент знает, а если это процедура, которая неоднократно используется. Зачем платформе думать за программиста? Может ещё искусственный интеллект в компилировании применять? Скулю по большому для внутренней производительности счету всё равно, параметр это или константа

(46) А какая связь между 1с и хранимыми процедурами? Зачем 1с вообще связываться с процедурами и прочими диалектами.. проще писать запросы в SQL-92 стандарте и не заморачиваться - они на любом сервере выполнятся одинаково..

(47) "какая связь между 1с и хранимыми процедурами?"
Прямая. Что ни на есть. sp_executesql() называется.

(47) "Зачем 1с вообще связываться с процедурами"
Кеш процедур, компиляция процедур... Не, никогда не слышал...

(37) > если только примитивные типы
А усложни запрос, чтобы не булево, а число было - код справочника там какой нибудь. Что покажет?

(50) да, так переменными. пока получается только с булево
WHERE (T1._Marked = 0x00) AND (T1._Posted = 0x00) AND (T1._Number = P1)',N'P1 nvarchar(4000)',N'5665'

даже элементарный запрос

(52) вида select &пар1 , если параметр дата, например - строит с переменными.

Это кстати, может связано с отличием, как скуль обрабатывает условия вида 1=0 (когда литерал) и @p1 = 0 (при @p1 = 1)

(49) Есть подозрение, что ресурсы, затраченные на компиляцию запросов в случае баз 1с, на несколько порядков меньше затраты ресурсов непосредственно на выборку данных. И поэтому кэш процедур - ненужная роскошь.

(55) Сомнение несколько необосновано.

(56) Неоднократно трассировал разные запросы, везде на построение плана тратились единицы-десятки миллисекунд. А непосредственно на выборку - значительно больше.

+(57) Это может для сайтов характерно, когда все запросы одинаковые, отличаются лишь параметрами, часто повторяются и обрабатывают немного данных.. там кэширование плана реально помогает. Но не для конфигураций 1с.

можно еще так

ГДЕ ЗаказКлиента.Статус.Порядок = 1

(58) Тут ты не прав. К примеру для добавление в список чего нибудь, каких нибудь колонок, к примеру для РН, выборка нескольких ПКО ( нал + оплата картой ). Так вот запрос ( не для уф. ) можно сделать переменной на Украине модуля и делать выборки для измененных данных списка, так вот объект Запрос повторяется многократно, а если несколько касс, так ещё и н на нескольких клиентах...

(60) "можно сделать переменной на Украине модуля"
Чувствуете ветерок? Это Фрейд в гробу завертелся ))

(61) Поезд, качка + т9. На уровне модуля.

(57) > Неоднократно

Как же замечательно, что платформу пишешь не ты.
Потрассируй что происходит при выводе списков там различных, формировании печатных документов. Неоднократно.

ИМХО, ТСу, как начинающему одинэснику, должно быть фиолетово, как влияет (и влияет ли) использование предопределенных значений вместо параметров в запросе. Потому что вероятность того, что из под клавиатуры сразу будут выходить оптимальные запросы, стремится к нулю, и на этом фоне, параметр там будет или не параметр - значения не имеет.

+(64) это примерно как недавний спор, по поводу того, что оптимальнее писать в условии Если:  x<>0 или Не(х=0)

(65) > Не(х=0)

Очень позитивный код. Сплошные смайлики!

(66) Ага (((

(63) "Потрассируй что происходит при выводе списков там различных, формировании печатных документов. Неоднократно."
Потрассировал. Ничего экстраординарного. Никаких сотен одинаковых запросов в секунду не происходит. Следовательно, выгоды от кэширования планов нет.

Само собой, г..окод никто не отменял, но в типовых такого нет.

(68) Продолжай наблюдения. Тебя ж просили - неоднократно.