Будет ли обращение к предопределенным данным или представлению ссылки запросом? Или предопределенные данные хранятся в конфе которая лежит у пользователя?

Допустим код

Для каждого стрТовары из тчТовары Цикл

    Если стрТовары.Номенклатура.ВидНоменклатуры = Перечисления.ВидыНоменклатуры.Услуга Товары

        Сообщить("Номенклатура"+стрТовары.Номенклатура+" - услуга?");
   КонеЕсли;

КонецЦикла;

стрТовары.Номенклатура.ВидНоменклатуры - это запрос

А вот
Сообщить("Номенклатура"+стрТовары.Номенклатура+" - услуга?");
Перечисления.ВидыНоменклатуры.Услуга

Это запросы?

Можете привести еще примеры не черных запросов?

При первом обращении к этой номенклатуре - запрос будет. При втором - уже закешируется. Ежов (вроде?) проводил такие эксперименты когда-то...

(1) В каком случае при  стрТовары.Номенклатура.ВидНоменклатуры или  Сообщить("Номенклатура"+стрТовары.Номенклатура+" - услуга?");

(2) Да.
Первая - точно будет обращение в БД и вытягивание всего.
Во втором - не знаю, как сейчас, может они представление оптимизировали.

(2) насколько я понимаю из статей в инете, получение всех свойств объекта с сервера будет по второй точке

т.е. при обращению к свойству объекта через точку провоцируется чтение объекта с сервера. Причем, считываться будет много раз, если будет будет встречаться чтение свойств много раз. Насколько оно закешируется и оптимизируется - тут судить трудно. А обращение будет каждый раз.

стрТовары.Номенклатура - это только использование Представления объекта, которе уже сформировано в тчТовары

(6) " использование Представления объекта, которе уже сформировано в тчТовары"
Кто тебе такое сказал?

(0) Сообщить("Номенклатура"+стрТовары.Номенклатура+" - услуга?");
Это однозначно запрос в цикле. не явный, на экзамене спеца по платформе за такое 2 балла снижают

(8) не думаю, что из-за запроса. Тут в сообщить указано неявное преобразование типа, которое мало того, что затратное по времени, но и может быть потенциальным источником ошибок.

(0) что мешает в запросе к ТЧ получить все представления и значение истины в случае если это услуга. и уже в цикле вывести результат

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

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

а потом уже вывести:

Пока Выборка.Следующий() цикл
Сообщить(""Номенклатура"+Выборка.НоменклатураПредставление+" - услуга");
КонецЦикла;

(12) там не ЗаказКлиентаТовары.ВидНоменклатуры а ЗаказКлиентаТовары.Номенклатура.ВидНоменклатуры разумеется (в том случае если в тч не выводится этот вид номенклатуры)

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

(14) Получение представления - это очень тормозная операция. Но не факт, что тормоза из-за этого. Лучше замерять производительность в конфигурации на тестовой.

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

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

(15) да, интересный пример.

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

(16) Да, поэтому эта функция и тормозная. Все функции написанные в SQL примерно в 10 раз медленнее решений обычным запросом.

(0) Предлагаю называть вещи своими именами. Запрос - это запрос средствами 1с. Обращение к реквизиту справочника (запросы к БД) - это нечто другое.

(18) Неявный запрос?

Конструкции вида стрТовары.Номенклатура.ВидНоменклатуры - это дополнительный запрос к БД.  На маленьких объемах проблем с этим не будет. Т.е. решение жизнеспособное.

Но... Если ты так напишешь на собеседовании - тебе скажут "А-та-та!". Хотя, повторюсь, что решение жизнеспособное. И удовлетворит 80% компаний.


Конструкции вида
Сообщить("Номенклатура"+стрТовары.Номенклатура+" - услуга?");  - вроде как к реквизиту не обращаешься. Но (!!!) при обращении к стрТовары программа тащит на клиента все реквизиты справочника. А это тоже обращение к реквизитам.

Моё мнение: решения такого вида возможны для небольшого объема данных (либо что-то разовое). Но на собеседовании нужно понимать, где тебя могут подловить.

(20) Это смотря куда собеседование. Во франч - это даже плюс. Потом можно будет еще раз деньги срубить за оптимизацию.

(20) все так, но в данном конкретном контексте стрТовары это не справочник, а просто элемент коллекции из тчТовары.
Поэтому в обращении
ДайМнеЗначениеСсылка = стрТовары.Номенклатура
получишь именно ссылку

а в обращении
ДайМнеЗначениеСтрока = "Номенклатура "+стрТовары.Номенклатура+" - услуга?"
получишь неявное преобразование типов с использованием Представления для ссылки.
Можно на большом цикле даже потестировать, что дольше работает
СТРОКА(стрТовары.Номенклатура)
или
стрТовары.Номенклатура.Наименование
Только нужно не забывать, что в общем случае получение Наименование может оказаться нагружена кучей всех остальных свойств. Если свойств будет мало, то скорость может оказаться в пользу Наименования взамен получения Представления

Друзья, я не про оптимизацию вообще (тут написано очень много правильных вещей), а про конкретную функцию ПРЕДСТАВЛЕНИЕ(). Она начиная с 1С 7.7 по 8.3 была мягко говоря не быстрой.

(23) Вот эта конструкция Строка(Справочники.Номенклатура.ПустаяСсылка()) - вызывает функцию Представление().

(22) на сколько я помню получение Наименования работает несколько быстрее чем получение Представление. Потому что для Представления через "менеджер чего-то там" получается сначала значение Основного представления (по коду или наименованию) а потом уже это само представление. (15) погонял в отладке, выдает замер один в один в клиент-серверном варианте. но опять же, на экзамене за левое соединение там где оно не нужно, снизят балл.

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

(25) Тестировали меня раз у одного работодателя по схеме франчайзи (1с экзамен). Проверяющий говорит у вас запрос не оптимально написан. Говорю давайте проверим. Проверили мой работает быстрее. Проверяющий - по правилам 1С он не оптимальный.

В общем не взяли меня на ту работу. А левое соединение, если не нужно, то планировщик SQL запроса сам его выкинет (в общем лишним не бывает).

(27) Это к вопросу "А судьи кто?".

Вернемся к теме.



Так я и не понял  ..." + стрТОвары.Номенклатура +" ... - это запрос к БД?



+
Обращение к перечислению это запрос к БД?

Обращение к предопределенному элементу это запрос к БД?

+ Есть ли еще такие неявные конструкции которые являются обращением к БД? Например ПараметрыСеанса или еще какой вариант?

(29) В Сообщить() это приводит к вызову обработчика ОбработкаПолученияПредставления(), где может выполняться любой код (на усмотрение разработчика конфигурации), в том числе могут быть запросы.

(29) >>Так я и не понял  ..." + стрТОвары.Номенклатура +" ... - это запрос к БД?

Ну если у тебя ".Номенклатура" имеет тип СправочникСсылка, есть какие-то сомнения, что это не запрос к БД?

такая оптимизация конечно хороша, но обычна она стоит в самом конце реальных косяков

единственное, что к документам с большими ТЧ лучше через точку не обращаться

(32) Вопрос не про оптимизацию. Вопрос больше теоретический. (33) Это понятно. Но в сообщить точки нет. И как насчет предопределенных элементов?

(26) в том то и смысл, в запросе получили только те записи для которых нужно вывести сообщение, и только для них получили представление

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

(36) > оно нужно только

Это абстрактный пример, ничего никому не нужно.

Вопрос не про оптимизацию, а про то, что является запросом и какие бывают еще.

(37) ЗАпросом является то, в результате чего идёт select в БД

(38) Слишком общий ответ. Меня конкретные примеры интересуют.

(15) А 1с разве сама не превратит первый запрос во второй? С учетом того что поле "Номенклатура" не составное

(39) Зато весьма точный. Данные лежат в таблицах БД. Если надо что-то оттуда достать - будет запрос. Надо достать наименование, чтобы вывести на экран - будет запрос.

(41) Как насчет перечислений, предопределенных элементов?

(42) Ссылку на значение перечисления - похоже читает один раз при обращении к перечислению, из таблицы config, и кэширует.

(43) Каждый раз читает, если обращаешься не через ПредопределенноеЗначение. Если через него, то кэшируется на время сеанса.

(44) Фиг знает, в обычном приложении вроде не вижу повторных запросов, если получаю через Перечисления.ИмяПеречисления.ИмяЗначения.

(29) Если тчТовары - это табличная часть объекта, то:
1. А = стрТовары.Номенклатура; // нет запроса в БД - объект считан в оперативу со всеми потрохами
2. Б = стрТовары.Номенклатура.ВидНоменклатуры; // есть запрос в БД для получения ссылки на вид номенлатуры
3. В = ""+стрТовары.Номенклатура; // есть запрос для получения представления

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

(47) В документации написано:

Перечисления

Для каждого перечисления создается таблица (_Enum<n>) с полями:

    _ID<suff> - идентификатор элемента перечисления;
    _EnumOrder - числовое значение элемента перечисления.


Если у справочника есть предопределенные данные, то создается таблица  проинициализированных областей (_RefSInf) с полями:

    _PDInitialized – признак того, что область проинициализирована;
    _Fld<n> - общие реквизиты данного объекта.

Хотя в рекомендациях 1С использование предопределенных элементов допустимо:

Процедура ОбработкаПроведения(Отказ, Режим)



Движения.ОсновнойРегистрБухгалтерии.Записывать = Истина;



Для Каждого ТекСтрокаТовары Из Товары Цикл

Движение = Движения.ОсновнойРегистрБухгалтерии.Добавить();

Движение.СчетДт = ПланыСчетов.ОсновнойПланСчетов.Товары;

Движение.СчетКт = ПланыСчетов.ОсновнойПланСчетов.Поставщики;

Движение.Период = Дата;

Движение.Организация = Организация;

Движение.Сумма = ТекСтрокаТовары.Сумма;

Движение.КоличествоДт = ТекСтрокаТовары.Количество;

Движение.Содержание = "Покупка товара";

Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Номенклатура] = ТекСтрокаТовары.Номенклатура;

Движение.СубконтоДт[ПланыВидовХарактеристик.ВидыСубконто.Склады] = Склад;

Движение.СубконтоКт[ПланыВидовХарактеристик.ВидыСубконто.Контрагенты] = Поставщик;



КонецЦикла;

https://its.1c.ru/db/pubapplied/content/189/hdoc

(46) 1. А = стрТовары.Номенклатура;// нет запроса в БД - объект считан в оперативу со всеми потрохами
@

С какого перепою? В тз лежит только ссылка

(50) Так тут и оперирование только ссылкой.

(0)Откройте для себя профайлер чтоли ....потрассируйте

(51) Где тут? Всё зависит от того, что с этой ссылкой сделать. Если её присвоить другой ссылке - то запроса не будет. Если попытаться от этой ссылки что-то взять - то бедт.

(52)> Откройте для себя профайлер чтоли ....потрассируйте

Это что такое?

Да мне особо глубоко не надо. Просто на следующей неделе веду курсы по введению в программирование в 1С, просто примеры запросов в цикле нужны.

(54) Если ты не знаешь, что такое профайлер - то есть мнение, что тебе вести курсы ещё рановато.

>> "Откройте для себя профайлер чтоли ....потрассируйте" - А что это такое?
в сочетании с
>> на следующей неделе веду курсы по введению в программирование в 1С
- это пять!

мда...
Но проблема еще и в том, что замер производительности в 1С есть, но профайлера как такового в самой 1С нету.

Пятничная тема!

(57) Профилер - он бдориентированный...

(56) да ладно, курсы по введению же. читать по методичке, которую тебе предоставят и все, там не надо быть классным спецом. синтаксис да пунктуация...

(59) А с учетом того, что у 1С есть "файловый режим" должен быть и свой. Логично просто, если бы он был

(60) И запросы на бумажке рисовать можно ))

(61) На все 5 вариантов? Это 5 разных профилеров должно быть..

(54) Гы-гы-гы... И эти люди нас потом учат, как правильно...

(50) ну, так и в приведенном МНОЮ коде используется только ссылка, гуид то есть

(48) из написанного не следует ни что запрос есть, ни что запросов нет. Нигде не написано, как платформа с метаданными обращается, в какой момент и в каком объеме она их вычитывает из БД

(64)> И эти люди нас потом учат, как правильно...

Поделись, где ты такое увидел?

(64) это не вас, это баранов

(54) Тогда открой для себя замер производительности и лови тормозящие места. Там довольно очевидно ловятся чтения из БД одного и того же по 100 тыс. раз

(54) а кто сказал что запросы в цикле это плохо?

(70) Методологи 1С? Пользователи у которых тормозит? Нет?

(71) бггг, а можно ссылку на методолгов?

(71) интересно, а что скажет Белоусов по поводу использования циклов при решении расчетных задач, да и в целом....

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

в случае получения спрТовары.Номенклатура.ВидНоменклатуры однозначно будет запрос к бд,и кеширование вас спасет только при втором запуске,т.к.обычно,в табличной части товары дублей номенклатуры нет.

запрос в цикле,сам по себе,не так страшен
но,во-первых,1с не умеет prepare execute,во-вторых,получение обьекта в цикле требует работы с блокировками,чтобы была целостность данных и не зависела от скорости выполнения и параллельнлсти.

(70) я

(76) у Вас есть уникальная возможность посетить курс ТС...

(77) Увлекаешься запросами в цикле? Видно за живое задело.

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

(77) дерзишь, шельма

(80) ни в коем случае, а вот на личности не нужно

(78) нет, я знаю как их готовить...

+(82) (78) А Вы?

?

(76) ну в общем... если у цикла немного повторений и если эти запросы не создают проблем (нагрузка, блокировки и т.п.) - это не проблема.

(77) Консультант Баранов читает какие-то курсы?

(85) это всегда не проблема, а просто новая задача в будущем. Если ты решил задачу путем запросов в цикле, то ты сделал из одной задачи две.

Запросы в цикле, в особенности неявные, - это само по себе не хорошо и не плохо. Это просто возможность, которую предоставляет платформа. Было бы это безусловно плохо, не было бы такой возможности.
При этом, если ты соорудил запрос в цикле, то это ты не решение сгенерировал, а техдолг, который потом придется отрабатывать.
А так как эта штука приводит не к исключениям, а к деградации производительности, узнаешь ты про что настал момент, когда пришла пора вернуть долги, не явно сразу и напрямую, а через длительный баттхёрт и период отрицания, гнева, непонимания и отчаяния, который тебе понадобится, чтобы найти, где из тебя кровь течёт.

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

(87) я всё это знаю, но чаще приходится перепиливать уже чужое и когда ищешь место которое проблема - запросы в цикле таковыми являются достаточно редко

(87) Это вообще спорный вопрос. Что лучше - простой запрос в цикле, который всегда однозначно оптимально выполняется серверов, или пятиэтажный единственный запрос, склонный падать в нестедлуп по миллионным таблицам. В первом случае ты получишь результат за предсказуемое время, во втором - время будет зависеть от фаз луны.

(88) а я и не для тебя это писал, а для коллеги, который считает, что носки можно не стирать потому, что они и так прекрасно работают.

(89) в том, что я написал, спорных вопросов нет. Перечитай. Я не писал, что запросы в цикле использовать нельзя и что они - абсолютное зло. Я написал, что их использование имеет цену, которую ПРИДЕТСЯ платить, но есть шанс, что - не тебе.

(89) ну запросы тоже не все умеют писать.... товарища дельфины (да, у нас кое какой софт по работе с железяками пишут на Delphi) крайне негодовали что наш сервер не тянет их запросы... на поверку они там соединяли 14 таблиц в одном запросе пакета!!! Оптимизатор за контрольное время тупо не успевал нормальный план выбрать.

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

(93) ты чего доказать-то хочешь?

(94) Что нет зла и добра, есть решение, которое делает программист.

(95)что за позорный инфантилизм!
Либо есть границы ответственности у каждого либо есть коллегиальная безответственность!

(96) Я не считаю запросы в цикле злом. Всё зависит от критериев. Если критерием является понятный и простой алгоритм, легко поддерживаемый и расширяемый - то лучше запрос в цикле, чем мегазапрос на 10 экранов. Даже если при этом мы теряем в быстродействии. В то же время, типовые тормозят жутко, несмотря на то что они пишутся по всем "рекомендациям" от 1с и там нет запросов в цикле, зато куча запросов там где не надо, например вместо обращения к контексту происходит запрос к данным объекта и тому подобное..

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

(97) ну слишком смелое обобщение, что в типовых 1С нет запросов в цикле. В конечном итоге, неявные запросы все равно встречаются довольно часто.

(85) согласен, если количество итераций можно контролировать и если выполнение не затрачивает много ресурсов, то можно решать НЕКОТОРЫЕ задачи, цикл в запросе ни плохо, ни хорошо, что бы это использовать, нужно знать все минусы и к чему может привести использование данных конструкций и в корне не согласен с адептами хорошего-белого и черного-плохого

(86) Немного расширенный: https://1c.ru/cso-part/rus/partners/training/cso/course?id=1

Единоразово, больше не ожидается.