В запросе пришлось добавить ЕСТЬNULL

    "ВЫБРАТЬ
    |    ТБ.Цена КАК БазоваяЦена,
    |    ТЦ.Цена КАК Цена,
    |    &НоваяЦена КАК НоваяЦена,
    |    ТБ.Номенклатура КАК Номенклатура,
    |    ТБ.Характеристика КАК Характеристика,
    |    ТБ.ЕдиницаИзмерения КАК ЕдиницаИзмерения
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ) КАК ТБ
    |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦен) КАК ТЦ
    |        ПО ТБ.Номенклатура = ТЦ.Номенклатура
    |            И ТБ.Характеристика = ТЦ.Характеристика
    |ГДЕ
    |    ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена";    


Новая цена - это сложное условие, зависящее от ТБ.Цена.

По сути, если старая цена ТЦ.Цена <> новой расчетной цене, то по этой позиции должна записываться новая цена.

Но не работало, попадали только те записи, где была хоть одна запись по цене, т.е. перерасчет цен работал, а добавление новой цены не работало.

Почему так? Оно что, считало что NULL <> Произвольное число - всегда истина?

Хотя вопрос снимается, погонял вот такой запрос:

ВЫБРАТЬ 1 ГДЕ 1 = NULL

Оказывается, что булевы выражения в 1С запросах могут принимать Истина, Ложь, NULL и отбирается только Истина.

Условие ГДЕ на Левую таблицу превращает соединение во внутреннее

так если добавление, то старой цены нет и в выборку соответственно не попадет

(2) в данном случае не превращает

(2) нет. там именно что логическое условие возвращает NULL, а в итог проходят только те логические условия, что возвращают Истина. Троичная булева логика, итить-колотить.
(3) нет

(3) в выборке ТБ есть, базовая цена, левое присоединяет ТЦ.Цена, которое равно NULL и оно именно и режется логическим условием.

Условно:
ТБ
пиво 100
водка 20

ТЦ
Пиво 150

До где результат будет:

Пиво 100, 150
водка 20, NULL

Вот второй NULL при сравнении с новой ценой вернет NULL и будет обрезан

(6) так НоваяЦена = NULL что ли

(7) так у тебя е ЕСТЬNULL, откуда там NULL ?

(9) +1

вот это ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена не может быть нулом

|ГДЕ
    |    (ТЦ.Цена есть null) ИЛИ (ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена)";

(0) деградация Гения как она есть
https://www.youtube.com/watch?v=EXCd3_CJLBQ&ab_channel=ауегор

> ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних

То есть, если у тебя нет текущей цены, то и результат пустой, хоть ты что в ГДЕ напиши

>>>
водка 20, NULL
Вот второй NULL при сравнении с новой ценой вернет NULL и будет обрезан


Это пять!.

Если что, в (0) вообще NULL нигде нет ...

(7) тебя удивляет, что сравнение с NULL не выполняется как ИСТИНА?
да, там NULL как результат сравнения

«Закусывать надо»

Раньше было так:  ТЦ.Цена <> &НоваяЦена, я ж написал что вставил ЕСТЬNULL

(17) да, удивляет

(20) в запросах сравнение с нулл всегда дает нулл.

(20) мне жаль тебя
но зато ты узнал что-то новое в этом мире, это прекрасно

(19) зачем?

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

(23) нет, не одинаковые, виды цен там разные ТБ (закупочная) ТЦ (розничая)

(22) жалко у пчелки в жопке. ;-)

(23) +
точнее можно только в случае если поле СУММА в SQL имеет признак "разрешен null", но в 1с такое я еще не встречал

(21) век живи, век учись, не знал такого. Или забыл... Вроде когда-то уже сталкивался.

(28) ну что ты, это не я, это Нуралиев и Ко

(29) все же описано на ИТС https://its.1c.ru/db/metod8dev/content/2512/hdoc

(0) Оставим в стороне null-ориентированный разум Г1С, у него еще и запрос попой писан.

(30) Имхо, если бы Гений читал ИТС, мы бы не наблюдали столько гениальных вопросов от него :)

(20) читай доку, любая операция с нул возвращает нул

(33) это относится к булевым операторам, но не к специализированым функциям

Чего вернут следующие конструкции:

1. ЕСТЬNULL(NULL, 0)
2. (NULL есть NULL) = True

(34) это относится не только к булевым, правда другие операции вызовут ошибку

(31) так не зря ж его именуют null-битный Гений.

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

Как я понимаю, можно проверить, NULL столбец или нет. Прочие сравнения с NULL никогда не бывают равенством и даже NULL <> NULL, потому что это могут быть NULLы от разных типов данных.

(38) Вообще не поэтому.

Везде будет 0, и нет тут столбцов и типов.

SELECT
     iif(NULL = NULL, 1, 0)
    ,iif(NULL > NULL, 1, 0)
    ,iif(NULL < NULL, 1, 0)

Результат будет по колонкам: 1,2,3,4

SELECT
     min(t.q)
    ,max(t.q)
    ,min(t.w)
    ,max(t.w)
FROM (
    SELECT
          1 as q,    NULL as w
    UNION ALL SELECT NULL, 3
    UNION ALL SELECT NULL, 4
    UNION ALL SELECT 2, NULL
    ) as t

(38) еще раз, null-ов от разных типов данных не бывает.
Null - это отсутствие значения.
И два отсутствия точно также возвращают отсутствие,как и одно.

NULL сам по себе специальный тип данных с единственным значением NULL.
И есть только единственный вариант проверить NULL там или нет - это или функция ISNULL(<ПроверемоеЗначение>, ЗначениеЕслиИстина, ЗначениеЕслиЛлжь) или специальный оператор сравнения IS NULL.

(0) тебе доплачивают за нечитабельные имена и псевдонимы таблиц в запросах? Или ты на общественных началах говнокодишь?

(30) он не читает документацию

(43) Я тоже даю имена часто т, т1, т2...
Если запрос простой, из нескольких запросов и подзапросов, то логику проще видеть не вдаваясь в то как таблица называется. А то длинные и похожие имена пока прочитаешь...
Суть логики воспринимается быстрее с короткими именами.

В случае в (0) вообще соединение не нужно. Выборка идет срезом на одну дату из одного и того же РС.

(0)

ВЫБРАТЬ
...
МАКСИМУМ(ВЫБОР КОГДА т.ВидЦен = &ВидЦенБазовый ТОГДА т.Цена ИНАЧЕ NULL КОНЕЦ) КАК БазоваяЦена
МАКСИМУМ(ВЫБОР КОГДА т.ВидЦен = &ВидЦен_НЕ_Базовый ТОГДА т.Цена ИНАЧЕ NULL КОНЕЦ) КАК НЕ_Базовая_Цена
...
ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен В (&ВидЦенБазовый, &ВидЦен)) КАК т
...
СГРУППИРОВАТЬ ПО
...

Смотрим в (40) как работают функции максимума и минимума со значением NULL.

(43) Что там нечитабельного? Ты две буквы прочесть не можешь?
Вот имена ттттттттттттттт и тттттттттттттт действительно нечитабельны. А ТЦ и ТБ самое то

Интересно какова была логика разработчиков SQL, когда решили что NULL не равно NULL

(49) хотелось бы увидеть примеры, когда это реально нужно

(49) При чем тут логико разработчиков SQL?
Всегда считал что это математика - теория множеств.

(51) в теории множест есть NULL?
Есть пустое множество, но оно таки равно себе

(49) Одно неизвестное не равно другому неизвестному

(48) за невнятными именами может прятаться ошибка, которую разглядишь ты только с 15-го раза

(54) конечно имя ЦеныНоменклатурыСрезПоследних куда лучше

(54) ТЦ и ТБ внятные имена. Легко отличимы друг от друга

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

(55) Ага, ага. А вторая таблица ЦеныНоменклатурыСрезПоследнихЕщеРаз

(56) он стороник имен а ля
ГенераторКомпоновкиДанныхВТабличныйДокументИмениБорисаГеоргиевичаНуралиева

(56) в них разница, на минуточку, в одной единственной букве. Спутать проще простого. К тому же ТЦ и ТБ неминуемо заставляет сбегать глазами в секцию from за расшифровкой этого ребуса

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

(60) Как можно спутать букву "Ц" и "Б"?

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

(61) вот в этом и беда нашей 1сной отрасли, тут говнокодить считается нормой

>>зрелые мужи знают, что этот код никто читать не будет

Сам-то ты чужой код никогда не читаешь, не? Каждый раз код пишешь с чистого листа?

(63) такую переменную пока прочтешь уже забудешь зачем пришел

(62) элементарно, если смотришь на код третий час подряд

(64) Конечно читаю. Но у меня оперативная память хорошая. Тренированная. Мне пофиг на имена. Чем короче, тем лучше. А если у тебя сложности с чтением кода, то вот тут действительно стоит подумать о смене профессии.

(67) И что минифицированный js смогешь осилить?

(65) зато ГК - огонь! Читается моментально, только абсолютно непонятно, что оно такое. Уходы в верх, ради поиска первисточника этого недоразумения, конечно же способствует вспоминанию, зачем пришел

(64) "вот в этом и беда нашей 1сной отрасли, тут говнокодить считается нормой" - говнокодят везде и все.
Проблема отрасли 1С в том, что код получается длиннее на несколько порядков, чем в других языках. И с этим сделать ничего невозможно.
Даже банальный SQL запрос будет трёхэтажный и трех километровый.

(69) У тебя оперативная память малоемкая

(67) причем тут память? Речь о том, что из внятного имени можно сразу понять цель и значение переменной/метода. Ох уж эти 1сники, как мать роднуб защищают привычки говнкодить

Трехэтажный и трехкилометровый код автоматически считается говнокодом.

(71) не пиши бред

(72) Притом, что хорошая память позволяет не прыгать туда-сюда по коду, а просто помнить, что означает то или иное имя

(58) В случае в (0) вообще вторая таблица не нужна. Смотреть (47).

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

Если переменная дальше 1 экрана не уходит, то без разница какое имя

(75) может ещё и телепатические способности развивает? Что делает метод ПослЗн() ? А хрена ты скажешь. Чтобы ответить на этот вопрос, придется занырнуть в метод и изучить его. Будь у метода внятное имя, не пришлось бы даже заглядывать в него

Если таблиц всего от 1 до 5, то вообще по фигу как они называются. Чем короче - тем проще. А ещё лучше их просто пронумеровать.

(79) Речь про названия таблиц в запросах, а не про имена функций и названием методов объектов. Это слишком разные вещи.

(78) зачем бегать искать пояснения к переменной, когда сама переменная могла обо всём рассказать

(81) нет уж, манера говнокодить, она всеобъемлющая и вездесущая

(82) Совсем не всегда.
for i=1 ...

(84) угу, а чтобы расшифровать переменную с емким именем Тз, нужно сбегать через три процедуры вверх по стеку. Лепота!

Я обычно в пакете все запросы нумерую,и имена стараюсь давать как можно короче.
Другое дело,что ТЦ это таблица цен,и очень удобно ее просто назвать Цены.
Когда у вас несколько выборок цен,то или вы получаете длинные ничего не объясняющие наименования или приходите к виду ц1 и т.л. можно,конечно,ЦВчера и ЦСегодня.
К именам функций это тоже относится.

Ну и проблема длинных имен в том,что ВыбратьАктуальныеЦены или ПолучитьАктуальныеЦены оба названия канонические и красивые,но если забываешь,какое из них было,то надо лезть смотреть,а если лезть смотреть,то какая разница,что там написано ? Понятно,что за ВАЦ будет стыдно,а все остальное - не важно.

(86) >>вы получаете длинные ничего не объясняющие наименования

Как страшно жить... А поясняющие имена никак не присвоить, не?

(87)в 1с в запросах нет комментариев.
Для функции,я привык писать комментарии,чтобы было понятно,что и как.

(84)
Для ИндексСтрокиНормативныхПотерь=0 По...
Для СчетчикПорцииДанных=0 По...
Для НомерЗапросаВПакете=0 По...

(88) Есть.

(88) хорошие имена не нуждаются в комментариях. Но верится с трудом, что жалеешь время на выбор "говорящего" имени переменной/методу, но не жалеешь времени на написание комментариев

(49) логика такая: если у вас одно значение неизвестно и второе неизвестно, то их равенство тоже неизвестно и неравенство неизвестно. А состояние неопределенности при приведении к булевому типу обычно транслируется в ложь, т.е. NULL=NULL обычно false и NULL<>NULL тоже false. Но это не точно :))) В некоторых диалектах SQL может быть немного по-другому, причем это может регулироваться настройками.

Гарантировано (всегда, в любом SQL) то, что любое определенное значение <>NULL, скажем, 1<>NULL, 'Вася'<>NULL, 20.05<>NULL.
Но я лично стараюсь избегать любых сравнительных конструкций с NULL, кроме IS NULL и IS NOT NULL, тем более что это не так уж сложно делать.

(90) Покеж.

(94) двойная косая, также как и в коде. Можно прямо в тексте делать что-то типа
|// И ЭтоУсловиеНеБудетПроверяться

(88) > в 1с в запросах нет комментариев.

Какая раскрывающая тема. Это же вы всё по поводу пятницы, да?

До этого дня я думал что самым днищем является мнение, что в запросах 1С нет HAVING, потому что его не осиливают найти в конструкторе.

(94) Сначало запишитесь в очередь просителей починки конструктора запросов, который сносит комментарии.

(97) так это... можно ж тупо на английский перевести ИМЕЮШИЕСЯ или ИМЕЮЩИЕ и погуглить

предложение SELECT норм перенесено в 1С со всеми фичами. Главное русский перевод найти :)
Вот чего не отсыпали, так это встроенных функций. Но это другое.

(90) в принципе,можно в тексте запроса использовать //
А можно даже между строками текста просто комментарий вставлять - он будет зеленый.
Но,при открытии такого запроса в конструкторе это все теряется.

(86) в циклах ты же пишешь i и j, почему в таблицах писать другое. ТЦ - таблица цен текущих, ТБ - таблица цен базовых. Коротко и ясно, если что, можно комментарий ниже текста запроса написать. Я всегда даю короткие имена, если 2-3 таблицы. Если больше,  то уже пишу ТЦены, ТОстатки. Зато мои запросы легко читать, а не эта боль, которая сопровождает чтение запросов 1С

(102) i,j в циклах пишут только гении.

(103) еще Страуструп и Кнут, знаешь таких?

(104) которые писали в 80-ые, и приходилось экономить даже на текстах кода.

эти названия переменных доведены до абсурда. Например в названии переменной 8 слов, если например читаешь шестое слово в названии, то уже забыл, что там было в первом-втором слове. И когда прочитал название переменной полностью, нет никакой уверенности, что это именно та переменная, о которой ты подумал, вдруг существуют 2 или 3 переменные с похожими названиями. И они там различаются несколькими буквами.

(103) А специалисты в области Data science все поголовно пишут X, y, pd... И всем все понятно

(102) >>ТЦ - таблица цен текущих, ТБ - таблица цен базовых

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

(104) не помазывайся к этим людям, они впринципе не разделяют твои говнокодерские позиции

"Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, что бы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу" (с) Бьёрн Страуструп

(106) ага, ага. Ведь проще прочитать имя переменной "ТЗнач", а потом прочитать ещё несколько сотен строк кода, чтобы понять что за ТЗнач стояла коллекция контрагентов с просроченной кредиторской задолженностью. Читать сотни строк кода не так обременительно, как прочитать внятное имя "КонтрагентыСПросроченнойКредиторскойЗадолженностью"

(107) чушь

(109) у тебя компульсивное расстройство на почве перфекционизма

(110) не путай написание понятного кода с перфекционизмом. Книжки умные почитай. Например, "Рефакторинг. Улучшение существующего кода" от Мартина Фаулера. Много нового для себя откроешь
https://www.ozon.ru/product/refaktoring-uluchshenie-sushchestvuyushchego-koda-1308678/?sh=0wEGM5F3Ew

(111) основная проблема рефакторинга - отсутствие тестов

(112) основная проблема рефакторинга - неумение и нежелание его проводить

(113) проблема - денег нет, но вы держитесь

Ибо желание должно возникнуть на более высоком уровне

(115) на каком более высоком? Руководство всей душой заинтересовано, чтобы ты писал читабельный, легко сопровождаемый код. А не мешанину, в которой в будущем будут гибнуть лишние человекочасы. Руководители могут не знать о последствиях плохого кода, но они заинтересованы в снижении стоимости владения кодом

(116) поэтому на предложение о рефакторинге скорее всего будет ответ: а х..ли ты сразу не писал как надо

(43) +1 тоже обратил внимание. имена таблиц и параметра
я бы не пропустил такое на ревью

(78) сегодня не уходит, а завтра уже ушла

в стандартах разработки есть пункт про именование переменных

(119) так это виноват тот кто накорячивает элементарный код

(117) во-во. И в этом суть нашей отрасли. Низкая культура разработки тут повсеместность. Спроси на какой-нибудь прогерской конференции, нужно ли проводить рефакторинг. Да на тебя посмотрят как на дурачка, спрашивающего "нужно ли мыться?"

(120) там не пункт, там несколько разделов про имена. Другое дело, что Г1Сы даже не считают нужным читать какие-либо стандарты

(123)
"даже не считают нужным читать"
->
даже не знает о их существовании"

(121) да и когда видишь ВидЦенБ - мозг невольно должен напрягаться, т.к. это не русский язык
хоть немного но мозгового ресурса потратиться

(125) немного потратится на попытку разгадать эту шифровку. А потом потратится ещё больше мозгового ресурса на выведение сути ВидЦенБ из контекста

Раньше были компилляторы,в которых задавалась длина идентификатора - все идентификпторы,которые в пределах длины совпадали,считались одним,я так на ассемблере такую собаку съел,что длинные имена считаю глупостью,и если где-то можно использовать короткие,то буду.
Опять же,длина идентификатора в 1С насколько я помню, 80 символов.

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

(127) что ассемблеры из 50-х не позволяли писать длинные имена, это конечно же весомый аргумент, почему на 1с нужно писать короткие имена. Ага.
Тот промышленный код на ассемблере, который я видел, сопровождался комментариями для каждой (!) строки. И такой подход был средством уменьшения боли, вызываемой короткими именами

По поводу имен переменных:
В 1с не требуется явное описание переменных,а все общие модули торчат в пространство имен контекста напрямую,и проблема наступает,когда имя нашей переменной совпадает с именем общего модуля или чего-то еще,торчащего в контексте.
К счастью,в языке запросов мы свободны от этого и можем называть временные таблицы как угодно.

(128) "нетривиальный путь в запросе" - отдельный вид зла

(116) как забавно. А типовой код от 1С соответствует твоим высоким требованиям? Спрошу еще - как думаешь, конфигурации от 1С проходят автоматическое тестирование (при том что на дворе 2022 год)? А?
Вот и не ной. Когда вендор покажет пример, тогда и на местах подтянутся.

(120) поэтому эти "стандарты" и не уважают, что вилами по воде писаны

(132) нет, не соответствуют. В фирме 1с тоже полно рукожопов. Хотя ни один из них не сравнится с тобой

(133)АПК напрммер,не любит,чтобы в имени переменной были русские и латинские буквы вместе.
Но,в 1с так и остались HttpСоединение и ЧтениеXML
Короткие имена переменных еще плохи тем,что нечаянно можно задействовать уже занятую переменную.
Понятно,что в использовании i как счетчика цикла проблем нет,если тело цикла помещается на экране,а если оно на несколько экранов,то при доработке и желании вставить внутрь еше один цикл можно в нем использовать i со всеми вытекающими последствиями

(132) кто не уважает? Только рукожопы не уважают

Я видел людей,которые на Си код в строку писали опрераторы через точку с запятой.
В 1с так тоже можно,но ведь никто так не делает,поэтому,какую-то часть стандартов все соблюдают.

(131) типовой код далеко не идеален. Но он на порядок лучше и понятнее твоего

(138) спасибо за бесплатный аудит моего кода, но хотелось бы деталей, что именно улучшить там и т.п. в этом роде. Чтобы чуть больше чем 0 бит информации было.

(137)  к сожалению некоторые так делают, по логике что у него всего одна строка решает задачу. Круто же. Обычно это болезнь новичков

Крутизна однострочников вовсе не в том чтобы написать много операторов через точку с запятой. Круто - когда это неожиданная, нечасто применяемая конструкция, которая тем не менее компилируется и решает задачу. В основном это практикуется на С (++), Perl, JS и Python.

Вот, например https://m.youtube.com/watch?v=LkHCy5JZtsA

(141)я именно говорил о записи операторов,разделенных точкой с запятой или двоеточием,что используется,когда операторы из разных строк объединяют в одну.
Понятно,что,если мы выполняем последовательность простых функций,каждая из которых получает результат из предыдущей функции и передает последующей,то это логично записать в одну строку,чтобы не вводить временные переменные.
Тем более,что в случае 1с переменная определяется на всю функцию сразу.
С другой стороны,когда отлаживаешь код,то удобнее,чтобы каждое действие было в одной строке и можно было посмотреть промежуточный результат.

Потом,есть языки,как javascript,где результатом присваивания является присвоенное значение и можно птсать множественные присваивания.
А уже про расточивание (когда мы получаем поле объекта,который сам поле другого объекта),я уже молчу.
Ну и если взять,к примеру,bash,там очень много чего делается в одну строку.

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

(30) В этой документации указано, что null смысла сравнивать нет, но если после соединения поле цена встанет в null, а потом заменится с помощью функции ЕСТЬNUL на другое значение, то сравнивать вполне себе нормально. Если запись отбрасывается, то это явный баг

(141) я про другое - про конструкции: если а=б тогда выполнить1() конецесли
или еще более навернутые. Новичкам кажется что чем более накрученна и непонятна строка тем лучше
а то по твоей ссылке - такие fluid однострочники нередко тоже есть смысл разбивать по строкам для читабельности, если они сложные:
Employee emp1 = new Employee.EmployeeBuilder()
    .empNo(100)
    .name("Brijesh")
    .projectName("Builder Pattern")
    .build();

ну и так же поступать с регулярками. и комментировать их
var r = new RegExp(
    '('      + //start capture
    '[0-9]+' + // match digit
    ')'        //end capture
);
r.test('9');

(139) топик-то перечитай

(143) "следование стандарту приводит к некоторому замедлению кода"
хорошее уточнение - "к некоторому"
там обращение к базам данных погасит подобные микрооптимизации

(145) с регулярками ты это конечно пошутил

(148) а что не так? если регулярка сложная

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

(150) а в чем проблема?

(151) проблема в ьом что читабельности не добавит ни капли

Регулярки они такие как ни риши получается ж.

(153) какие то общие слова

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

вот пример.  главное прокомментировать хорошо
Pattern re = Pattern.compile(
  "^\\s*"+
  "(?:"+
    "(?:"+
      "([\\d]+)\\s*:\\s*"+  // Capture group #1
    ")?"+
    "(?:"+
      "([\\d]+)\\s*:\\s*"+  // Capture group #2
    ")"+
  ")?"+ // First groups match 0 or 1 times
  "([\\d]+)"+ // Capture group #3
  "(?:\\s*[.,]\\s*([0-9]+))?"+ // Capture group #4 (0 or 1 times)
  "\\s*$"
);

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

https://translated.turbopages.org/proxy_u/en-ru.ru.22406b64-6289f2de-765fb9ea-74722d776562/https/softwareengineering.stackexchange.com/questions/194975/readable-regular-expressions-without-losing-their-power

(143) ты что-то путаешь

(156) и что это проще читать?
Можно сходу сказать о чем оно?

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

Но можно и поближе посмотреть. Попробуй сложный sql запрос в одну строку вытянуть, сразу понятность запроса в труху

(158) я тебе передаю суть, что разбитие по строкам, отступы и комментарии добавляют читабельности, а ты за конкретный пример цепляешься
там тоже кооментарии абстрактные типа // Capture group #1
напиши туда конкретику и все будет понятно

(159) написание через точку с новой строки - это совсем другое.
Странно что ты разницы не видишь

(162) что совсем другое? Я бы сказал так - размазывание кода в одну устроку убъет абсолютно любой код

+а кто тебе сказал, что в функциональных языках точка с запятой в конце строки?

https://clojure.org/about/functional_programming

глянь на синтаксис

(144) не, бага нет, у меня код возвращал NULL, а он отбрасывался в ГДЕ

(166) если в где было без естьnull(), тогда левое соединение заменяется законно на внутреннее, что несколько ускоряет запрос, в противном случае, левое должно оставаться и зазвращать 100% записей из таблицы ТБ

(167) заменяется законно на внутренее , если есть условие сравнения без естьnull

(168) В примере в (0) вообще соединение не нужно. Выше писал почему.

(166) в (168) + к (169) писал в (47).

Про именование переменных, это вечный спор о вечном. :-)

(169) и почему же?

(172) ответ в (40), (46), (47).

(172) Я ответил на вопрос: Почему?

(171) это про комменты
А именование +- регламентировано

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

По запросам ещё проще. Конструкции стандартные, количество операторов наверное меньше чем команд в ассемблере.
Комментировать особо не чего. Тут практически не алгоритм, а описание результата. Если таблиц штук пять или меньше и связи простые, то фиолетово какие будут имена у таблиц. FROM всегда где-то рядом. Можно просто т1, т2...
Если есть вложенная одинокая таблица в подзапросе, то внутри можно просто т. По умолчанию предлагает ВложенныйЗапрос, но проще просто т.

Т.е.
Выбрать
     ИмяТаблицы1.Поле1
    ,ИмяТаблицы2.Поле1
ИЗ
     ИмяТаблицы1 как ИмяТаблицы1
    ,(выбрать т.Поле1 из КакаяТоТаблица как т где т.Поле1 = 0) как ИмяТаблицы2

Я про алиас "т" таблицы "КакаяТоТаблица", который внутри подзапроса.

(176) "По запросам ещё проще" - ага, когда 100500 таблиц во менеджерах временных таблиц. А потом еще всякие вложенные таблицы внутри вложенных таблиц и все обезличенные - ммм какая красота, как же все легко читается и понятно, что автор хотел в этом запросе)

(177) Прикинь и это только в 1С такой треш. А знаешь почему? SQL стандарт 10-ти летней давности. + Недостаток функционала в тех же функциях. Математические функции только добавили.

Это я к чему. Ко скольким физическим таблицам обращается этот километровый запрос?

(176)  я не спрашивал, нужны ли комментарии

(179) Извини, но я так понял твой пост.

(178) трэш в запросах, потому что 1сники повадились напичкивать запросы сложной логикой, где только можно. Коллективная такая болезнь

(181) Какая ещё сложная логика? А чем речь?

(182) ну когда начинаются невнятные условия соединений, портянки выбор когда... тогда..., переливания данных через пятнадцать временных таблиц

вот такое авно в том или ином виде растеклось по 100500 модулям в типовых конфигурациях


    Сумма * ВЫБОР
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 0.18
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 0.1
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.БезНДС)
            ТОГДА 0
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 0.2
        ИНАЧЕ 0
    КОНЕЦ КАК СуммаНДС

(184) это вы еще лесенку с родителями не скинули))

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

(183) "портянки выбор когда... тогда..." - Для простых конструкций есть короткая конструкция IIF(Условие, РезультатЕслиИстина, РезультатЕслиЛожь), но только не в 1С.
"переливания данных через пятнадцать временных таблиц" - это как правило из-за отсутствия оконных функций, а так же простых функций без временных таблиц RANK(),  DENSE_RANK(), ROW_NUMBER().

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

(186) Нет. Подобные задачи не в 1С тоже решают с помощью SQL запроса, но выглядит это всё компактно и понятно.

(187) какие "подобные"? я не говорил ни о каких то конкретных задачах

(187) так про то и речь, что 1сный SQL чрезвычайно ограниченный. На кой в него пихать то, что гораздо проще сделать на встроенном языке? Код на встроенном языке обладает несравнимо большей гибкостью, чем запросы. Ну получи ты данные из табличек, соедини их, а потом во встроенном языке прогони через код

(188) Любые подобные. Не решает же 1С какие-то задачи, которые решает только 1С. Скорее наоборот - 1С не решает многих задач, которые решают не на 1С. Собственно так можно не только про 1С говорить. Всегда есть какой-то аналогичный инструмент, который может решать аналогичные задачи.

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

(191) например, что запрос может ускорить в (184)?

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

Мне таки интересно Серёжа ответит на мой вопрос в (174).
"(172) Я ответил на вопрос: Почему?"

(191) общий случай - называется преждевременной оптимизацией, если ты понимаешь о чем я

(195) вот да, преждевременная оптимизация - отдельный вид зла. Который не намного лучше дублирования в коде. А уродливые запросы это прям комбо. Тут и дублирование (одно и то же растаскивается по множеству запросов), и преждевременная оптимизация

(192) Цепонуть сразу короткую таблицу, в которой напротив каждой ставки уже свой коэффициент: 0, 0.1, 0.18, 0.2...
По скорости внутреннее соединение короткой таблицы, будет быстро, а копипаста минимум.
Что бы не было по "100500 модулям в типовых конфигурациях". Таблица же статическая. При запуске создал и юзай везде.

При добавлении новой ставки в 17%, достаточно при запуске поправить создание таблицы. Код будет статичный.

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

(198) так не сделали этого сразу же. Поэтому добавление двух несчастных значений в перечисление привело к исправлениям в 100500 запросам. Самое интересное, отдельной таблички со ставками тут и не нужно было. Достаточно было при обходе выборки звать функцию вычисления ставки НДС. Если СКД, то в вычисляемых полях ту же функцию дёргать

Вот, запросная наркомания из типовой. Запрос сам себя дублирует

ВЫБРАТЬ
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.КоличествоДоИзменения >= КорректировкаПоступленияТовары.Количество
            ТОГДА &ИсправляемыйДокументПоступления
        ИНАЧЕ &СчетФактура
    КОНЕЦ КАК СчетФактура,
    &ИсправляемыйДокументПоступления КАК Партия,
    &Склад КАК Склад,
    ЗНАЧЕНИЕ(Перечисление.ВидыЦенностей.ПустаяСсылка) КАК ВидЦенности,
    КорректировкаПоступленияТовары.Номенклатура КАК Номенклатура,
    КорректировкаПоступленияТовары.СтавкаНДС КАК СтавкаНДС,
    КорректировкаПоступленияТовары.Количество - КорректировкаПоступленияТовары.КоличествоДоИзменения КАК Количество,
    ВЫБОР
        КОГДА НЕ КорректировкаПоступленияТовары.Ссылка.СуммаВключаетНДС
            ТОГДА КорректировкаПоступленияТовары.Сумма + КорректировкаПоступленияТовары.СуммаНДС - (КорректировкаПоступленияТовары.СуммаДоИзменения + КорректировкаПоступленияТовары.СуммаНДСДоИзменения)
        ИНАЧЕ КорректировкаПоступленияТовары.Сумма - КорректировкаПоступленияТовары.СуммаДоИзменения
    КОНЕЦ КАК Стоимость,
    КорректировкаПоступленияТовары.СчетУчета КАК СчетУчета,
    КорректировкаПоступленияТовары.СчетУчетаНДС КАК СчетУчетаНДС,
    КорректировкаПоступленияТовары.Ссылка.Дата КАК Период,
    КорректировкаПоступленияТовары.Ссылка.Организация КАК Организация,
    КорректировкаПоступленияТовары.НомерСтроки КАК НомерСтроки,
    КорректировкаПоступленияТовары.Ссылка КАК Регистратор,
    ЛОЖЬ КАК НоваяСтрока,
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 20 / 120
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 18 / 118
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 10 / 110
        ИНАЧЕ 0
    КОНЕЦ КАК СтавкаНДСМножитель
ИЗ
    Документ.КорректировкаПоступления.Товары КАК КорректировкаПоступленияТовары
ГДЕ
    КорректировкаПоступленияТовары.Ссылка = &Ссылка
    И (КорректировкаПоступленияТовары.КоличествоДоИзменения - КорректировкаПоступленияТовары.Количество <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаНДСДоИзменения - КорректировкаПоступленияТовары.СуммаНДС <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаДоИзменения - КорректировкаПоступленияТовары.Сумма <> 0)
    И КорректировкаПоступленияТовары.КоличествоДоИзменения <> 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    &СчетФактура,
    &ИсправляемыйДокументПоступления,
    &Склад,
    ЗНАЧЕНИЕ(Перечисление.ВидыЦенностей.ПустаяСсылка),
    КорректировкаПоступленияТовары.Номенклатура,
    КорректировкаПоступленияТовары.СтавкаНДС,
    КорректировкаПоступленияТовары.Количество,
    ВЫБОР
        КОГДА НЕ КорректировкаПоступленияТовары.Ссылка.СуммаВключаетНДС
            ТОГДА КорректировкаПоступленияТовары.Сумма + КорректировкаПоступленияТовары.СуммаНДС
        ИНАЧЕ КорректировкаПоступленияТовары.Сумма
    КОНЕЦ,
    КорректировкаПоступленияТовары.СчетУчета,
    КорректировкаПоступленияТовары.СчетУчетаНДС,
    КорректировкаПоступленияТовары.Ссылка.Дата,
    КорректировкаПоступленияТовары.Ссылка.Организация,
    КорректировкаПоступленияТовары.НомерСтроки,
    КорректировкаПоступленияТовары.Ссылка,
    ИСТИНА,
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 20 / 120
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 18 / 118
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 10 / 110
        ИНАЧЕ 0
    КОНЕЦ
ИЗ
    Документ.КорректировкаПоступления.Товары КАК КорректировкаПоступленияТовары
ГДЕ
    КорректировкаПоступленияТовары.Ссылка = &Ссылка
    И (КорректировкаПоступленияТовары.КоличествоДоИзменения - КорректировкаПоступленияТовары.Количество <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаНДСДоИзменения - КорректировкаПоступленияТовары.СуммаНДС <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаДоИзменения - КорректировкаПоступленияТовары.Сумма <> 0)
    И КорректировкаПоступленияТовары.КоличествоДоИзменения = 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

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

(200) а как надо было?

(201) проблема со ставками НДС не была бы проблемой, если бы 1сники не вычисляли её в запросе

(201) справочник все равно не поможет ибо жесткая привязка колонок к ставкам

(200) Я так понимаю разница тут:
В выбрать
ЛОЖЬ КАК НоваяСтрока,

и в условии

И КорректировкаПоступленияТовары.КоличествоДоИзменения = 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

(202) Выбор когда добавь и радуйся.

(202) вангую КорректировкаПоступленияТовары.СтавкаНДС.Множитель и все - без всяких выбор когда))

(202) простейшим запросов выбрать данные из ТЧ, потом обойти в цикле, делая вычисления. Код стал бы и короче, и намного читабельнее. Самое главное, его не пришлось бы перепахивать при появлении новых ставок НДС

(205) во-во-во! Отдельный ребус найти разницу в этих двух почти одинаковых запросах. Отдельная удача не допустить ошибку при их доработке...

(207) Не проще. Если этот код при проведении, то вот эти туды-сюды данных ооооочень медленно.
И зачем вычислять, если можно просто соединить и получить нужный коэффициент сразу. Вопрос только в отсутствии таблицы, построенной по статическим данным "Перечисление.СтавкаНДС". Создать служебный РС строить его при запуске 1С и не жужжать.

(207) для типовой это сомнительные плюсы

(209) а зачем туды-сюды? Один раз получил данные запросом, и шлифуй их в коде. Один фиг ты притащишь эти данные на сервер, чтобы запихать в наборы записей

>>И зачем вычислять

Вот и у меня вопрос. Зачем делать вычисления в запросе? Они уродливые и приводят к дублированию

"Строить при запуске 1С" - имеется ввиду при необходимости. При обновлении, например, когда это необходимо.

Мне таки интересно Серёжа ответит на мой вопрос в (174).

Звучал он примерно так: "(172) Я ответил на вопрос: Почему?".

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

(0)
Хорошо когда о причине введения функции ЕстьNULL() задумываешься не после собеседования, а в результате тестирования своего запроса.
Опыт ценен. Лучше поздно (с несколькими сертификатами), чем никогда.

Казалось бы парадокс "NULL <> NULL", но с другой стороны отсутствие значения в разных физических таблицах дает один и тот же NULL.
И приравнивать их это терять физический смысл.
Ввели эту функцию, что бы разработчик обозначил пустые значения.

(0)
Убивать за такие запросы надо )))
Шутка. Не рационально.

Если "Характеристика" это измерение, то еще интереснее. )
Если оно не используется, то зачем в итоговую таблицу выбирать?
Если используется активно, то ... .

Если реквизит, то видимо другое дело.

Короче я в шоке ))). Вникать не хочется в чужую кухню.

Удачи Серега.

Да нет поспешил вроде норм. Конец дня.
Но все равно я бы по другому написал.
Все мы разные.

(217) взад беру.

(216) оставлю

Типа мое мнение ) Которое не имеет смысла )

Яркий пример что сертификаты ничего не гарантирую )

(218) Перфекционист что ли? НЕ люблю перфекционистов, они убогие стандарты 1с-разработки пишут.

(220) Мне таки интересно Серёжа ответит на мой вопрос в (174).
Звучал он примерно так: "(172) Я ответил на вопрос: Почему?".

Уже чисто спортивный интерес.

Если кто-то говорит,что в 1с сложные запросы,то пусть чистый sql посмотрит,где хранимые процедуры - вот где внсело и интересно,когда те же "модули",но внутри sql.

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

(221) сформулируй вопрос целиком. Если ты считаешь, что IN лучше чем JOIN, то мы на разных сторонах силы. ОК?

(220)

Норм. Не обиделся.

Всегда потом можно деньги на оптимизации взять.
Кто-то костыли ставит. Кто-то снимает.
Так и зарабатываем.

Некоторые любят посидеть подождать пока запрос отработает )
Особенно если почасовка идет.

(224) У тебя в IN всего два значения и этот IN в параметрах виртуальной таблицы.
Можешь написать не IN а "Условие1" ИЛИ "Условие2". Опа, и нет никакого IN.

А у тебя две выборки из одного источника данных, да ещё и левое соединение потом. Ты соединяешь таблицу саму с собой, при этом таблица используется как есть.
Т.е. одно дело ты в таблице нашел МАКС или МИН или ещё что и потом соединяешь уже преобразованную таблицу с исходной таблицей. А другое дело просто саму исходную таблицу саму с собой - в этом нет никакого смысла. Она у тебя и при первой выборки уже есть.

(199) там они молятся на то, чтобы все вычисления были в запросах. поэтому я и не уважаю стандарты 1С-совместимо. Это не практическое руководство, а религиозное

(194) таки сформулируй вопрос целиком, я запутался в твоих цикличных ссылках

(228) Чего его там формулировать. Зачем левое соединение таблицы самой с собой?

(227) Это в каком стандарте описано?

(227) бред же. Ты стандарты даже не читал

из стандартов, касательно твоих болячек в (0)

Псевдонимы источников данных в запросах

Псевдоним источника данных должен быть осмысленным, чтобы было понятным его назначение в данном контексте. Требования к псевдонимам источников схожи с требованиями к именам переменных в коде.

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

(232) а из двух можно, ггг? ну что за бред, что за иллюзии в голове этих писателей стандартов?

(233) бред это твой код, а в стандартах все нормально. Что, стандарт задевает твои говнокодерские привычки?

у меня привычка - передаваемую ТЗ как параметр алиасить как Т
ибо такой запрос(на выборку из параметра) обычно пишу руками, привычка - ибо не сразу понял , где в конструкторе этот механизм ))

(228) И.... ? Опять я не сформулировал вопрос что ли?

(226) какой такой один источник? там две таблицы с разными видами цен.
Да, можно использовать:
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен)

Но там надо не просто макс или мин цену определить, а иметь для расчета цену ВидЦенБ (от нее расчитывается новая цена) и сравинвать с ценой ВидЦен.

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

Но если ты считаешь что нет, будь добр, сделай рефакторинг этого запроса на:

РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен)

(237) В (47) же написал уже.

(237) "Но там надо не просто макс или мин цену определить" - а где вообще макс или мин цена?

(238) э нет, дядя, ты напиши весь запрос, как минимум на СГРУППИРОВАТЬ ты уже попал. Не думаю, что твоя экономия на соединить дала тебе какой-то выигрыш. Весь запрос будет монструозным, в отличии от моего, а выигрыша по производительности не будет, план запроса будет ужасным.

Побаловался для практики )

"ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
|ПОМЕСТИТЬ НовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена,
|    ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения
|ПОМЕСТИТЬ БазовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    БазовыеЦены.Номенклатура КАК Номенклатура,
|    БазовыеЦены.Характеристика КАК Характеристика,
|    БазовыеЦены.БазоваяЦена КАК БазоваяЦена,
|    БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
|    ЕстьNULL(НовыеЦены.Цена,0) КАК Цена
|ИЗ
|    БазовыеЦены КАК БазовыеЦены
|        ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены
|        ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура
|            И БазовыеЦены.Характеристика = НовыеЦены.Характеристика
|ГДЕ
|    ЕстьNULL(НовыеЦены.Цена,0) <> &НоваяЦена"

Можно еще запросы 1 и 2 переставить и выбирать только присутствующие пары Номенклатура + Характеристика из полученной таблицы предвосхищая левое соединение,
но очень похоже что экономии не будет.

"ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена,
|    ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения
|ПОМЕСТИТЬ БазовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
|ПОМЕСТИТЬ НовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
|            &Дата,
|            ВидЦены = &ВидЦены
|                И (Номенклатура, Характеристика) В
|                    (ВЫБРАТЬ РАЗЛИЧНЫЕ
|                        БазовыеЦены.Номенклатура КАК Номенклатура,
|                        БазовыеЦены.Характеристика КАК Характеристика
|                    ИЗ
|                        БазовыеЦены КАК БазовыеЦены)) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    БазовыеЦены.Номенклатура КАК Номенклатура,
|    БазовыеЦены.Характеристика КАК Характеристика,
|    БазовыеЦены.БазоваяЦена КАК БазоваяЦена,
|    БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
|    ЕСТЬNULL(НовыеЦены.Цена, 0) КАК Цена
|ИЗ
|    БазовыеЦены КАК БазовыеЦены
|        ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены
|        ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура
|            И БазовыеЦены.Характеристика = НовыеЦены.Характеристика
|ГДЕ
|    ЕСТЬNULL(НовыеЦены.Цена, 0) <> &НоваяЦена"

&НоваяЦена КАК НоваяЦена,

Смысла не имеет. Если только не используется дальше.
Проще при переборе выборки подставить куда надо константу единую для всей выборки.

Возможно есть смысл из-за того при последнем варианте будет задействован первичный индекс.
Ну да не важно ))))

(240) Ты же даже не пробовал.

(0) Почему нет связи по "ЕдиницаИзмерения"?
В общем случае одна и та же номенклатура с ценой за килограмм и за центнер, упаковка и коробка 10 шт, и т.д.
Или в вашем случае у номенклатуры всегда одна "ЕдиницаИзмерения"? А вдруг кто-то двойника штук сделает?

(240) Для затравки....
Запрос по характеристикам

(240) не-а. Твой план запроса будет плохим, а его отработает оптимально

+(249) не гарантированно, но с большой долей вероятности будет плохим... Про это на ИТС написано, который ты не читал

https://its.1c.ru/db/v8std/content/655/hdoc

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

И слился....

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

(247) в нашем случае не сделают.

(250) дружок, а где ты у меня вложенный запрос увидал? гггг

(254) Справа от левой таблицы и слева от правой )))

(255) не гони

(256) Срез последних - это не таблица, это запрос

(253) В ссылку в (248) зайди. Может что-то не очевидное увидишь.

"Не волнуйтесь, если что-то не работает. Если бы всё работало, вас бы уволили."

(254) открою тебе страшную тайну: все виртуальные таблицы в запросах 1с по-факту являются вложенными запросами. Стыдно гуриям такое не знать

(252) "Поэтому ты и не пишешь хотя бы примерный текст запроса" - написан примерный текст запроса ещё в (47).

(261) это только декларация намерений. ггг..

(260) вложенные запросы это то, что находится в операторе IN

(263) не только

Оператор IN не ошибается, если используется выборка из ВТ без условий, поэтому где-то когда-то был рекомендован к использованию. А в случае замены ИЛИ - прям обязан быть использованным

А виртуальные таблицы - это запрос с неизвестным объёмом результата

(263) не пиши ересь

Смотрю, кризис вайти неслабо тебя накрыл, раз элементарные вещи за столько лет не изучил

(263) Вложенный запрос - это запрос внутри запроса

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