ivanov660
Владимир Крючков

А не умрет 1С, если запросов будет много? Я так понимаю на каждую картинку, стили тоже запрос (кэширование на странице надеюсь включено).

(28)
1. посмотрите на вкладке релизы (https://github.com/Polyplastic/1c-parsing-tech-log/releases)
или тут https://github.com/Polyplastic/1c-parsing-tech-log/tree/master/parsing-tech-log-plugins/bin
2. без них используется функционал работы с технологическим журналом, т.е. в некоторых случаях этого может быть достаточно

(26) обновили

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

Давайте расскажу про некоторые моменты более подробно:

1. Обсудим условие НЕ.
Эффективность условий в большинстве случаев связана с использованием планировщиком СУБД индексов. Иными словами, если существуют индексные таблицы подходящие к каким-либо условиям отборов, то запрос будет более эффективен. Т.к. в противном случае будет использоваться полное сканирование, а это перебор всей таблицы - в противовес получения нескольких значений сразу.

Индексы, в основном, могут использоваться для операторов равно (=), больше (>, меньше (< и их комбинаций. И не могут использоваться для условий НЕ. Но это не значит, что требуется всегда избавляться от такого условия. В некоторых случаях такие условия могут довольно сильно порезать количество данных передаваемых на следующий уровень плана запроса, а это однозначно большой плюс.

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

2. Про получение некоторых данных заранее.
- Часто получают некоторые данные заранее, если планируется использовать их потом в нескольких местах сразу.
- Также значительно упрощается сам запрос - а это очень важно.
- Относительно накладных затрат, то получение валюты будет очень быстро и не скажется заметно на общей производительности этого куска кода в общем. Попробуйте взять и сравните, какую эффективность вы получите изменив такую конструкцию с базовой. Если будет 2%, то даже смысла об этом нет говорить.
- Вот как раз создание огромных конструкций запросов, который делает все и сразу приведет к тому, что поддерживаться такой код станет проблематично и не возможно. Поэтому такие оптимизации должны быть четко обоснованы, чтобы польза была больше чем сопутствующее проблемы.

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

P.S. Все пытаться оптимизировать нет смысла. И всегда надо придерживаться критерия эффективности и целесообразности выполненных работ.

(3)
1. Для художественного произведения или области работы с сотрудниками, такой подход приемлем и звучит здорово. Но в данном случае, часть озвученных вами решений не выдерживает критики. О чем я и написал.
Приведите доказательства того что ваше предложение действительно оптимизирует, тогда скорее всего все вопросы снимутся.
2. Зачем ссылаться на неудачное решение? На мой взгляд, разумнее равняться на лучшего.

Цитата
Единственный путь стать умнее — играть с более сильным противником

Эмануэль Ласкер
P.S. Дали статью - получите замечания и защищайте свою позицию.

Утверждение "Мой внутренний голос говорит, что так лучше." - за гранью моего понимания для технической статьи, особенно по оптимизации, где порой важна каждая мелочь. На мой взгляд, должна прослеживаться четкая последовательность в виде: утверждение - доказательство.

Цитата
Я исключил условие "НЕ ЭтоГруппа". За свою практику мне ни одного раза не довелось встречаться с тем, чтобы пользователи использовали папки в справочнике ДоговорыКонтрагентов.

Вот я часто встречаюсь, что бухгалтера разбивают договоры по группам - комиссия, займ и т.д. И само наличие условия НЕ не снижает производительность как таковое, перепишите так ЭтоГруппа=Ложь, если напрягает НЕ.

В общем, мне не понравилось.

Интересно, а долгое первое открытие управляемой формы также пофиксили? Эта беда , к сожалению, проявляется при каждом новом открытии конфигуратора.

(1) Все в ваших руках)

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

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