|
Почему сравнение с NULL не работает ожидаемым образом? | ☑ | ||
---|---|---|---|---|
0
Гений 1С
гуру
20.05.22
✎
14:45
|
В запросе пришлось добавить ЕСТЬNULL
"ВЫБРАТЬ | ТБ.Цена КАК БазоваяЦена, | ТЦ.Цена КАК Цена, | &НоваяЦена КАК НоваяЦена, | ТБ.Номенклатура КАК Номенклатура, | ТБ.Характеристика КАК Характеристика, | ТБ.ЕдиницаИзмерения КАК ЕдиницаИзмерения |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ) КАК ТБ | ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦен) КАК ТЦ | ПО ТБ.Номенклатура = ТЦ.Номенклатура | И ТБ.Характеристика = ТЦ.Характеристика |ГДЕ | ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена"; Новая цена - это сложное условие, зависящее от ТБ.Цена. По сути, если старая цена ТЦ.Цена <> новой расчетной цене, то по этой позиции должна записываться новая цена. Но не работало, попадали только те записи, где была хоть одна запись по цене, т.е. перерасчет цен работал, а добавление новой цены не работало. Почему так? Оно что, считало что NULL <> Произвольное число - всегда истина? |
|||
1
Гений 1С
гуру
20.05.22
✎
14:47
|
Хотя вопрос снимается, погонял вот такой запрос:
ВЫБРАТЬ 1 ГДЕ 1 = NULL Оказывается, что булевы выражения в 1С запросах могут принимать Истина, Ложь, NULL и отбирается только Истина. |
|||
2
1Сергей
20.05.22
✎
14:53
|
Условие ГДЕ на Левую таблицу превращает соединение во внутреннее
|
|||
3
Выпрь
20.05.22
✎
14:56
|
так если добавление, то старой цены нет и в выборку соответственно не попадет
|
|||
4
Выпрь
20.05.22
✎
14:57
|
(2) в данном случае не превращает
|
|||
5
Гений 1С
гуру
20.05.22
✎
14:57
|
(2) нет. там именно что логическое условие возвращает NULL, а в итог проходят только те логические условия, что возвращают Истина. Троичная булева логика, итить-колотить.
(3) нет |
|||
6
Гений 1С
гуру
20.05.22
✎
14:58
|
(3) в выборке ТБ есть, базовая цена, левое присоединяет ТЦ.Цена, которое равно NULL и оно именно и режется логическим условием.
|
|||
7
Гений 1С
гуру
20.05.22
✎
14:59
|
Условно:
ТБ пиво 100 водка 20 ТЦ Пиво 150 До где результат будет: Пиво 100, 150 водка 20, NULL Вот второй NULL при сравнении с новой ценой вернет NULL и будет обрезан |
|||
8
Выпрь
20.05.22
✎
15:00
|
(6) так НоваяЦена = NULL что ли
|
|||
9
Выпрь
20.05.22
✎
15:01
|
(7) так у тебя е ЕСТЬNULL, откуда там NULL ?
|
|||
10
1Сергей
20.05.22
✎
15:02
|
(9) +1
|
|||
11
1Сергей
20.05.22
✎
15:02
|
вот это ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена не может быть нулом
|
|||
12
vde69
20.05.22
✎
15:03
|
|ГДЕ
| (ТЦ.Цена есть null) ИЛИ (ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена)"; |
|||
13
Ненавижу 1С
гуру
20.05.22
✎
15:10
|
(0) деградация Гения как она есть
https://www.youtube.com/watch?v=EXCd3_CJLBQ&ab_channel=ауегор |
|||
14
youalex
20.05.22
✎
15:13
|
> ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних
То есть, если у тебя нет текущей цены, то и результат пустой, хоть ты что в ГДЕ напиши |
|||
15
Ёпрст
20.05.22
✎
15:13
|
>>>
водка 20, NULL Вот второй NULL при сравнении с новой ценой вернет NULL и будет обрезан Это пять!. |
|||
16
Ёпрст
20.05.22
✎
15:14
|
Если что, в (0) вообще NULL нигде нет ...
|
|||
17
Ненавижу 1С
гуру
20.05.22
✎
15:15
|
(7) тебя удивляет, что сравнение с NULL не выполняется как ИСТИНА?
да, там NULL как результат сравнения |
|||
18
Aleksandr N
20.05.22
✎
15:20
|
«Закусывать надо»
|
|||
19
Гений 1С
гуру
20.05.22
✎
15:24
|
Раньше было так: ТЦ.Цена <> &НоваяЦена, я ж написал что вставил ЕСТЬNULL
|
|||
20
Гений 1С
гуру
20.05.22
✎
15:24
|
(17) да, удивляет
|
|||
21
Aleksandr N
20.05.22
✎
15:24
|
(20) в запросах сравнение с нулл всегда дает нулл.
|
|||
22
Ненавижу 1С
гуру
20.05.22
✎
15:26
|
(20) мне жаль тебя
но зато ты узнал что-то новое в этом мире, это прекрасно |
|||
23
vde69
20.05.22
✎
15:27
|
(19) зачем?
у тебя джойнятся две абсолютно одинаковые таблицы, при таком джойне нулл получить невозможно (ТБ и ТЦ - всегда одинаковые) |
|||
24
Гений 1С
гуру
20.05.22
✎
15:28
|
(23) нет, не одинаковые, виды цен там разные ТБ (закупочная) ТЦ (розничая)
|
|||
25
Гений 1С
гуру
20.05.22
✎
15:28
|
(22) жалко у пчелки в жопке. ;-)
|
|||
26
vde69
20.05.22
✎
15:29
|
(23) +
точнее можно только в случае если поле СУММА в SQL имеет признак "разрешен null", но в 1с такое я еще не встречал |
|||
27
Гений 1С
гуру
20.05.22
✎
15:29
|
(21) век живи, век учись, не знал такого. Или забыл... Вроде когда-то уже сталкивался.
|
|||
29
Гений 1С
гуру
20.05.22
✎
15:58
|
(28) ну что ты, это не я, это Нуралиев и Ко
|
|||
30
Kassern
20.05.22
✎
16:01
|
(29) все же описано на ИТС https://its.1c.ru/db/metod8dev/content/2512/hdoc
|
|||
31
H A D G E H O G s
20.05.22
✎
16:03
|
(0) Оставим в стороне null-ориентированный разум Г1С, у него еще и запрос попой писан.
|
|||
32
Fish
20.05.22
✎
16:06
|
(30) Имхо, если бы Гений читал ИТС, мы бы не наблюдали столько гениальных вопросов от него :)
|
|||
33
mikecool
20.05.22
✎
16:07
|
(20) читай доку, любая операция с нул возвращает нул
|
|||
34
vde69
20.05.22
✎
16:48
|
(33) это относится к булевым операторам, но не к специализированым функциям
Чего вернут следующие конструкции: 1. ЕСТЬNULL(NULL, 0) 2. (NULL есть NULL) = True |
|||
35
mikecool
20.05.22
✎
16:54
|
(34) это относится не только к булевым, правда другие операции вызовут ошибку
|
|||
36
lodger
20.05.22
✎
16:55
|
(31) так не зря ж его именуют null-битный Гений.
|
|||
37
ДедМорроз
20.05.22
✎
18:11
|
На самом деле,null это не значение,а флаг,что значения нет,соответственно никакие выражения не вычисляются,а в результат проставляется также null,что говорит,что результата нету.
|
|||
38
NorthWind
20.05.22
✎
18:20
|
Как я понимаю, можно проверить, NULL столбец или нет. Прочие сравнения с NULL никогда не бывают равенством и даже NULL <> NULL, потому что это могут быть NULLы от разных типов данных.
|
|||
39
Said_We
20.05.22
✎
18:42
|
(38) Вообще не поэтому.
Везде будет 0, и нет тут столбцов и типов. SELECT iif(NULL = NULL, 1, 0) ,iif(NULL > NULL, 1, 0) ,iif(NULL < NULL, 1, 0) |
|||
40
Said_We
20.05.22
✎
18:47
|
Результат будет по колонкам: 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 |
|||
41
ДедМорроз
20.05.22
✎
18:48
|
(38) еще раз, null-ов от разных типов данных не бывает.
Null - это отсутствие значения. И два отсутствия точно также возвращают отсутствие,как и одно. |
|||
42
Said_We
20.05.22
✎
18:51
|
NULL сам по себе специальный тип данных с единственным значением NULL.
И есть только единственный вариант проверить NULL там или нет - это или функция ISNULL(<ПроверемоеЗначение>, ЗначениеЕслиИстина, ЗначениеЕслиЛлжь) или специальный оператор сравнения IS NULL. |
|||
43
Конструктор1С
20.05.22
✎
18:57
|
(0) тебе доплачивают за нечитабельные имена и псевдонимы таблиц в запросах? Или ты на общественных началах говнокодишь?
|
|||
44
Конструктор1С
20.05.22
✎
19:00
|
(30) он не читает документацию
|
|||
45
Said_We
20.05.22
✎
19:05
|
(43) Я тоже даю имена часто т, т1, т2...
Если запрос простой, из нескольких запросов и подзапросов, то логику проще видеть не вдаваясь в то как таблица называется. А то длинные и похожие имена пока прочитаешь... Суть логики воспринимается быстрее с короткими именами. |
|||
46
Said_We
20.05.22
✎
19:07
|
В случае в (0) вообще соединение не нужно. Выборка идет срезом на одну дату из одного и того же РС.
|
|||
47
Said_We
20.05.22
✎
19:18
|
(0)
ВЫБРАТЬ ... МАКСИМУМ(ВЫБОР КОГДА т.ВидЦен = &ВидЦенБазовый ТОГДА т.Цена ИНАЧЕ NULL КОНЕЦ) КАК БазоваяЦена МАКСИМУМ(ВЫБОР КОГДА т.ВидЦен = &ВидЦен_НЕ_Базовый ТОГДА т.Цена ИНАЧЕ NULL КОНЕЦ) КАК НЕ_Базовая_Цена ... ИЗ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен В (&ВидЦенБазовый, &ВидЦен)) КАК т ... СГРУППИРОВАТЬ ПО ... Смотрим в (40) как работают функции максимума и минимума со значением NULL. |
|||
48
alarm2020
20.05.22
✎
19:26
|
(43) Что там нечитабельного? Ты две буквы прочесть не можешь?
Вот имена ттттттттттттттт и тттттттттттттт действительно нечитабельны. А ТЦ и ТБ самое то |
|||
49
Выпрь
20.05.22
✎
19:31
|
Интересно какова была логика разработчиков SQL, когда решили что NULL не равно NULL
|
|||
50
Выпрь
20.05.22
✎
19:32
|
(49) хотелось бы увидеть примеры, когда это реально нужно
|
|||
51
Said_We
20.05.22
✎
19:35
|
(49) При чем тут логико разработчиков SQL?
Всегда считал что это математика - теория множеств. |
|||
52
Выпрь
20.05.22
✎
19:36
|
(51) в теории множест есть NULL?
Есть пустое множество, но оно таки равно себе |
|||
53
alarm2020
20.05.22
✎
19:37
|
(49) Одно неизвестное не равно другому неизвестному
|
|||
54
Конструктор1С
20.05.22
✎
19:37
|
(48) за невнятными именами может прятаться ошибка, которую разглядишь ты только с 15-го раза
|
|||
55
Выпрь
20.05.22
✎
19:38
|
(54) конечно имя ЦеныНоменклатурыСрезПоследних куда лучше
|
|||
56
alarm2020
20.05.22
✎
19:39
|
(54) ТЦ и ТБ внятные имена. Легко отличимы друг от друга
|
|||
57
Конструктор1С
20.05.22
✎
19:40
|
Поражают люди, которые не то что не стремятсясделать свой код читабельнее, но и прилагают усилия, чтобы сделать его нечитабельным. Вы с профессией шиблись
|
|||
58
alarm2020
20.05.22
✎
19:40
|
(55) Ага, ага. А вторая таблица ЦеныНоменклатурыСрезПоследнихЕщеРаз
|
|||
59
Выпрь
20.05.22
✎
19:40
|
(56) он стороник имен а ля
ГенераторКомпоновкиДанныхВТабличныйДокументИмениБорисаГеоргиевичаНуралиева |
|||
60
Конструктор1С
20.05.22
✎
19:42
|
(56) в них разница, на минуточку, в одной единственной букве. Спутать проще простого. К тому же ТЦ и ТБ неминуемо заставляет сбегать глазами в секцию from за расшифровкой этого ребуса
|
|||
61
alarm2020
20.05.22
✎
19:42
|
(57) Успокойтесь, юноша! Вы еще слишком мало кодировали и слишком много значения придаете своему коду. А зрелые мужи знают, что этот код никто читать не будет, и в том числе, они сами
|
|||
62
alarm2020
20.05.22
✎
19:44
|
(60) Как можно спутать букву "Ц" и "Б"?
|
|||
63
Конструктор1С
20.05.22
✎
19:45
|
(59) такое имя намного лучше тупого и невнятного, абсолютно ничего не говорящего. Смысл которого нужно выводить из контекста, либо нырять вверх по стеку вызовов, чтобы понять что оно такое
|
|||
64
Конструктор1С
20.05.22
✎
19:47
|
(61) вот в этом и беда нашей 1сной отрасли, тут говнокодить считается нормой
>>зрелые мужи знают, что этот код никто читать не будет Сам-то ты чужой код никогда не читаешь, не? Каждый раз код пишешь с чистого листа? |
|||
65
Выпрь
20.05.22
✎
19:47
|
(63) такую переменную пока прочтешь уже забудешь зачем пришел
|
|||
66
Конструктор1С
20.05.22
✎
19:49
|
(62) элементарно, если смотришь на код третий час подряд
|
|||
67
alarm2020
20.05.22
✎
19:50
|
(64) Конечно читаю. Но у меня оперативная память хорошая. Тренированная. Мне пофиг на имена. Чем короче, тем лучше. А если у тебя сложности с чтением кода, то вот тут действительно стоит подумать о смене профессии.
|
|||
68
Выпрь
20.05.22
✎
19:52
|
(67) И что минифицированный js смогешь осилить?
|
|||
69
Конструктор1С
20.05.22
✎
19:52
|
(65) зато ГК - огонь! Читается моментально, только абсолютно непонятно, что оно такое. Уходы в верх, ради поиска первисточника этого недоразумения, конечно же способствует вспоминанию, зачем пришел
|
|||
70
Said_We
20.05.22
✎
19:54
|
(64) "вот в этом и беда нашей 1сной отрасли, тут говнокодить считается нормой" - говнокодят везде и все.
Проблема отрасли 1С в том, что код получается длиннее на несколько порядков, чем в других языках. И с этим сделать ничего невозможно. Даже банальный SQL запрос будет трёхэтажный и трех километровый. |
|||
71
alarm2020
20.05.22
✎
19:54
|
(69) У тебя оперативная память малоемкая
|
|||
72
Конструктор1С
20.05.22
✎
19:55
|
(67) причем тут память? Речь о том, что из внятного имени можно сразу понять цель и значение переменной/метода. Ох уж эти 1сники, как мать роднуб защищают привычки говнкодить
|
|||
73
Said_We
20.05.22
✎
19:55
|
Трехэтажный и трехкилометровый код автоматически считается говнокодом.
|
|||
74
Конструктор1С
20.05.22
✎
19:55
|
(71) не пиши бред
|
|||
75
alarm2020
20.05.22
✎
19:56
|
(72) Притом, что хорошая память позволяет не прыгать туда-сюда по коду, а просто помнить, что означает то или иное имя
|
|||
76
Said_We
20.05.22
✎
19:56
|
(58) В случае в (0) вообще вторая таблица не нужна. Смотреть (47).
|
|||
77
Конструктор1С
20.05.22
✎
19:56
|
(73) не считается, если его легко читать. Говнокодом считается мешанина из непонятных имен
|
|||
78
Выпрь
20.05.22
✎
19:56
|
Если переменная дальше 1 экрана не уходит, то без разница какое имя
|
|||
79
Конструктор1С
20.05.22
✎
19:59
|
(75) может ещё и телепатические способности развивает? Что делает метод ПослЗн() ? А хрена ты скажешь. Чтобы ответить на этот вопрос, придется занырнуть в метод и изучить его. Будь у метода внятное имя, не пришлось бы даже заглядывать в него
|
|||
80
Said_We
20.05.22
✎
20:00
|
Если таблиц всего от 1 до 5, то вообще по фигу как они называются. Чем короче - тем проще. А ещё лучше их просто пронумеровать.
|
|||
81
Said_We
20.05.22
✎
20:01
|
(79) Речь про названия таблиц в запросах, а не про имена функций и названием методов объектов. Это слишком разные вещи.
|
|||
82
Конструктор1С
20.05.22
✎
20:02
|
(78) зачем бегать искать пояснения к переменной, когда сама переменная могла обо всём рассказать
|
|||
83
Конструктор1С
20.05.22
✎
20:03
|
(81) нет уж, манера говнокодить, она всеобъемлющая и вездесущая
|
|||
84
Said_We
20.05.22
✎
20:03
|
(82) Совсем не всегда.
for i=1 ... |
|||
85
Конструктор1С
20.05.22
✎
20:06
|
(84) угу, а чтобы расшифровать переменную с емким именем Тз, нужно сбегать через три процедуры вверх по стеку. Лепота!
|
|||
86
ДедМорроз
20.05.22
✎
20:16
|
Я обычно в пакете все запросы нумерую,и имена стараюсь давать как можно короче.
Другое дело,что ТЦ это таблица цен,и очень удобно ее просто назвать Цены. Когда у вас несколько выборок цен,то или вы получаете длинные ничего не объясняющие наименования или приходите к виду ц1 и т.л. можно,конечно,ЦВчера и ЦСегодня. К именам функций это тоже относится. Ну и проблема длинных имен в том,что ВыбратьАктуальныеЦены или ПолучитьАктуальныеЦены оба названия канонические и красивые,но если забываешь,какое из них было,то надо лезть смотреть,а если лезть смотреть,то какая разница,что там написано ? Понятно,что за ВАЦ будет стыдно,а все остальное - не важно. |
|||
87
Конструктор1С
20.05.22
✎
20:19
|
(86) >>вы получаете длинные ничего не объясняющие наименования
Как страшно жить... А поясняющие имена никак не присвоить, не? |
|||
88
ДедМорроз
20.05.22
✎
20:25
|
(87)в 1с в запросах нет комментариев.
Для функции,я привык писать комментарии,чтобы было понятно,что и как. |
|||
89
H A D G E H O G s
20.05.22
✎
20:25
|
(84)
Для ИндексСтрокиНормативныхПотерь=0 По... Для СчетчикПорцииДанных=0 По... Для НомерЗапросаВПакете=0 По... |
|||
90
H A D G E H O G s
20.05.22
✎
20:26
|
(88) Есть.
|
|||
91
Конструктор1С
20.05.22
✎
20:28
|
(88) хорошие имена не нуждаются в комментариях. Но верится с трудом, что жалеешь время на выбор "говорящего" имени переменной/методу, но не жалеешь времени на написание комментариев
|
|||
92
NorthWind
20.05.22
✎
21:04
|
(49) логика такая: если у вас одно значение неизвестно и второе неизвестно, то их равенство тоже неизвестно и неравенство неизвестно. А состояние неопределенности при приведении к булевому типу обычно транслируется в ложь, т.е. NULL=NULL обычно false и NULL<>NULL тоже false. Но это не точно :))) В некоторых диалектах SQL может быть немного по-другому, причем это может регулироваться настройками.
|
|||
93
NorthWind
20.05.22
✎
21:08
|
Гарантировано (всегда, в любом SQL) то, что любое определенное значение <>NULL, скажем, 1<>NULL, 'Вася'<>NULL, 20.05<>NULL.
Но я лично стараюсь избегать любых сравнительных конструкций с NULL, кроме IS NULL и IS NOT NULL, тем более что это не так уж сложно делать. |
|||
94
Hans
20.05.22
✎
21:22
|
(90) Покеж.
|
|||
95
NorthWind
20.05.22
✎
21:33
|
(94) двойная косая, также как и в коде. Можно прямо в тексте делать что-то типа
|// И ЭтоУсловиеНеБудетПроверяться |
|||
96
vierzehn
20.05.22
✎
21:42
|
(88) > в 1с в запросах нет комментариев.
Какая раскрывающая тема. Это же вы всё по поводу пятницы, да? |
|||
97
vierzehn
20.05.22
✎
21:43
|
До этого дня я думал что самым днищем является мнение, что в запросах 1С нет HAVING, потому что его не осиливают найти в конструкторе.
|
|||
98
H A D G E H O G s
20.05.22
✎
21:47
|
(94) Сначало запишитесь в очередь просителей починки конструктора запросов, который сносит комментарии.
|
|||
99
NorthWind
20.05.22
✎
21:51
|
(97) так это... можно ж тупо на английский перевести ИМЕЮШИЕСЯ или ИМЕЮЩИЕ и погуглить
|
|||
100
NorthWind
20.05.22
✎
21:56
|
предложение SELECT норм перенесено в 1С со всеми фичами. Главное русский перевод найти :)
Вот чего не отсыпали, так это встроенных функций. Но это другое. |
|||
101
ДедМорроз
20.05.22
✎
22:49
|
(90) в принципе,можно в тексте запроса использовать //
А можно даже между строками текста просто комментарий вставлять - он будет зеленый. Но,при открытии такого запроса в конструкторе это все теряется. |
|||
102
Гений 1С
гуру
21.05.22
✎
09:51
|
(86) в циклах ты же пишешь i и j, почему в таблицах писать другое. ТЦ - таблица цен текущих, ТБ - таблица цен базовых. Коротко и ясно, если что, можно комментарий ниже текста запроса написать. Я всегда даю короткие имена, если 2-3 таблицы. Если больше, то уже пишу ТЦены, ТОстатки. Зато мои запросы легко читать, а не эта боль, которая сопровождает чтение запросов 1С
|
|||
103
H A D G E H O G s
21.05.22
✎
10:43
|
(102) i,j в циклах пишут только гении.
|
|||
104
Гений 1С
гуру
21.05.22
✎
12:23
|
(103) еще Страуструп и Кнут, знаешь таких?
|
|||
105
H A D G E H O G s
21.05.22
✎
12:29
|
(104) которые писали в 80-ые, и приходилось экономить даже на текстах кода.
|
|||
106
hhhh
21.05.22
✎
12:33
|
эти названия переменных доведены до абсурда. Например в названии переменной 8 слов, если например читаешь шестое слово в названии, то уже забыл, что там было в первом-втором слове. И когда прочитал название переменной полностью, нет никакой уверенности, что это именно та переменная, о которой ты подумал, вдруг существуют 2 или 3 переменные с похожими названиями. И они там различаются несколькими буквами.
|
|||
107
alarm2020
21.05.22
✎
13:06
|
(103) А специалисты в области Data science все поголовно пишут X, y, pd... И всем все понятно
|
|||
108
Конструктор1С
21.05.22
✎
15:43
|
(102) >>ТЦ - таблица цен текущих, ТБ - таблица цен базовых
Эти шифровки понятны только тебе самому. Любой другой читатель твоего кода вынуждег будет сидеть и расшифровывать твои эти загадки, вынужденно бегая глазами туда-сюда (104) не помазывайся к этим людям, они впринципе не разделяют твои говнокодерские позиции "Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, что бы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу" (с) Бьёрн Страуструп |
|||
109
Конструктор1С
21.05.22
✎
15:52
|
(106) ага, ага. Ведь проще прочитать имя переменной "ТЗнач", а потом прочитать ещё несколько сотен строк кода, чтобы понять что за ТЗнач стояла коллекция контрагентов с просроченной кредиторской задолженностью. Читать сотни строк кода не так обременительно, как прочитать внятное имя "КонтрагентыСПросроченнойКредиторскойЗадолженностью"
(107) чушь |
|||
110
Выпрь
21.05.22
✎
15:55
|
(109) у тебя компульсивное расстройство на почве перфекционизма
|
|||
111
Конструктор1С
21.05.22
✎
15:58
|
(110) не путай написание понятного кода с перфекционизмом. Книжки умные почитай. Например, "Рефакторинг. Улучшение существующего кода" от Мартина Фаулера. Много нового для себя откроешь
https://www.ozon.ru/product/refaktoring-uluchshenie-sushchestvuyushchego-koda-1308678/?sh=0wEGM5F3Ew |
|||
112
Выпрь
21.05.22
✎
16:01
|
(111) основная проблема рефакторинга - отсутствие тестов
|
|||
113
Конструктор1С
21.05.22
✎
16:03
|
(112) основная проблема рефакторинга - неумение и нежелание его проводить
|
|||
114
Выпрь
21.05.22
✎
16:04
|
(113) проблема - денег нет, но вы держитесь
|
|||
115
Выпрь
21.05.22
✎
16:04
|
Ибо желание должно возникнуть на более высоком уровне
|
|||
116
Конструктор1С
21.05.22
✎
16:09
|
(115) на каком более высоком? Руководство всей душой заинтересовано, чтобы ты писал читабельный, легко сопровождаемый код. А не мешанину, в которой в будущем будут гибнуть лишние человекочасы. Руководители могут не знать о последствиях плохого кода, но они заинтересованы в снижении стоимости владения кодом
|
|||
117
Выпрь
21.05.22
✎
16:16
|
(116) поэтому на предложение о рефакторинге скорее всего будет ответ: а х..ли ты сразу не писал как надо
|
|||
118
vi0
21.05.22
✎
16:22
|
(43) +1 тоже обратил внимание. имена таблиц и параметра
я бы не пропустил такое на ревью |
|||
119
vi0
21.05.22
✎
16:24
|
(78) сегодня не уходит, а завтра уже ушла
|
|||
120
vi0
21.05.22
✎
16:26
|
в стандартах разработки есть пункт про именование переменных
|
|||
121
Выпрь
21.05.22
✎
16:26
|
(119) так это виноват тот кто накорячивает элементарный код
|
|||
122
Конструктор1С
21.05.22
✎
16:27
|
(117) во-во. И в этом суть нашей отрасли. Низкая культура разработки тут повсеместность. Спроси на какой-нибудь прогерской конференции, нужно ли проводить рефакторинг. Да на тебя посмотрят как на дурачка, спрашивающего "нужно ли мыться?"
|
|||
123
Конструктор1С
21.05.22
✎
16:28
|
(120) там не пункт, там несколько разделов про имена. Другое дело, что Г1Сы даже не считают нужным читать какие-либо стандарты
|
|||
124
H A D G E H O G s
21.05.22
✎
16:29
|
(123)
"даже не считают нужным читать" -> даже не знает о их существовании" |
|||
125
vi0
21.05.22
✎
16:30
|
(121) да и когда видишь ВидЦенБ - мозг невольно должен напрягаться, т.к. это не русский язык
хоть немного но мозгового ресурса потратиться |
|||
126
Конструктор1С
21.05.22
✎
16:34
|
(125) немного потратится на попытку разгадать эту шифровку. А потом потратится ещё больше мозгового ресурса на выведение сути ВидЦенБ из контекста
|
|||
127
ДедМорроз
21.05.22
✎
17:23
|
Раньше были компилляторы,в которых задавалась длина идентификатора - все идентификпторы,которые в пределах длины совпадали,считались одним,я так на ассемблере такую собаку съел,что длинные имена считаю глупостью,и если где-то можно использовать короткие,то буду.
Опять же,длина идентификатора в 1С насколько я помню, 80 символов. |
|||
128
ДедМорроз
21.05.22
✎
17:27
|
К сложному запросу,желательно,писать то,что должно получаться на выходе и как,так как даже очень понятные названия таблиц и полей не смогут сказать,что хотел автор,особенно,нсли он пошел нетривиальным путем.
|
|||
129
Конструктор1С
21.05.22
✎
17:34
|
(127) что ассемблеры из 50-х не позволяли писать длинные имена, это конечно же весомый аргумент, почему на 1с нужно писать короткие имена. Ага.
Тот промышленный код на ассемблере, который я видел, сопровождался комментариями для каждой (!) строки. И такой подход был средством уменьшения боли, вызываемой короткими именами |
|||
130
ДедМорроз
21.05.22
✎
17:34
|
По поводу имен переменных:
В 1с не требуется явное описание переменных,а все общие модули торчат в пространство имен контекста напрямую,и проблема наступает,когда имя нашей переменной совпадает с именем общего модуля или чего-то еще,торчащего в контексте. К счастью,в языке запросов мы свободны от этого и можем называть временные таблицы как угодно. |
|||
131
Конструктор1С
21.05.22
✎
17:35
|
(128) "нетривиальный путь в запросе" - отдельный вид зла
|
|||
132
Гений 1С
гуру
21.05.22
✎
17:35
|
(116) как забавно. А типовой код от 1С соответствует твоим высоким требованиям? Спрошу еще - как думаешь, конфигурации от 1С проходят автоматическое тестирование (при том что на дворе 2022 год)? А?
Вот и не ной. Когда вендор покажет пример, тогда и на местах подтянутся. |
|||
133
Гений 1С
гуру
21.05.22
✎
17:36
|
(120) поэтому эти "стандарты" и не уважают, что вилами по воде писаны
|
|||
134
Конструктор1С
21.05.22
✎
17:39
|
(132) нет, не соответствуют. В фирме 1с тоже полно рукожопов. Хотя ни один из них не сравнится с тобой
|
|||
135
ДедМорроз
21.05.22
✎
17:40
|
(133)АПК напрммер,не любит,чтобы в имени переменной были русские и латинские буквы вместе.
Но,в 1с так и остались HttpСоединение и ЧтениеXML Короткие имена переменных еще плохи тем,что нечаянно можно задействовать уже занятую переменную. Понятно,что в использовании i как счетчика цикла проблем нет,если тело цикла помещается на экране,а если оно на несколько экранов,то при доработке и желании вставить внутрь еше один цикл можно в нем использовать i со всеми вытекающими последствиями |
|||
136
Конструктор1С
21.05.22
✎
17:40
|
(132) кто не уважает? Только рукожопы не уважают
|
|||
137
ДедМорроз
21.05.22
✎
17:42
|
Я видел людей,которые на Си код в строку писали опрераторы через точку с запятой.
В 1с так тоже можно,но ведь никто так не делает,поэтому,какую-то часть стандартов все соблюдают. |
|||
138
Конструктор1С
21.05.22
✎
17:42
|
(131) типовой код далеко не идеален. Но он на порядок лучше и понятнее твоего
|
|||
139
Гений 1С
гуру
21.05.22
✎
21:11
|
(138) спасибо за бесплатный аудит моего кода, но хотелось бы деталей, что именно улучшить там и т.п. в этом роде. Чтобы чуть больше чем 0 бит информации было.
|
|||
140
vi0
22.05.22
✎
04:45
|
(137) к сожалению некоторые так делают, по логике что у него всего одна строка решает задачу. Круто же. Обычно это болезнь новичков
|
|||
141
NorthWind
22.05.22
✎
08:14
|
Крутизна однострочников вовсе не в том чтобы написать много операторов через точку с запятой. Круто - когда это неожиданная, нечасто применяемая конструкция, которая тем не менее компилируется и решает задачу. В основном это практикуется на С (++), Perl, JS и Python.
|
|||
142
NorthWind
22.05.22
✎
08:17
|
Вот, например https://m.youtube.com/watch?v=LkHCy5JZtsA
|
|||
143
ДедМорроз
22.05.22
✎
09:08
|
(141)я именно говорил о записи операторов,разделенных точкой с запятой или двоеточием,что используется,когда операторы из разных строк объединяют в одну.
Понятно,что,если мы выполняем последовательность простых функций,каждая из которых получает результат из предыдущей функции и передает последующей,то это логично записать в одну строку,чтобы не вводить временные переменные. Тем более,что в случае 1с переменная определяется на всю функцию сразу. С другой стороны,когда отлаживаешь код,то удобнее,чтобы каждое действие было в одной строке и можно было посмотреть промежуточный результат. Потом,есть языки,как javascript,где результатом присваивания является присвоенное значение и можно птсать множественные присваивания. А уже про расточивание (когда мы получаем поле объекта,который сам поле другого объекта),я уже молчу. Ну и если взять,к примеру,bash,там очень много чего делается в одну строку. Опять же,вернемся к 1с. Структуру можно определять в строку,задав имя и потом значения,но в стандарте 1с рекомендует не использовать такое определение для более чем трех значений. В функцию можно передавать любое число аргументов,но в стандарте пишут,что желательно не более восьми,предлагая вводить промежуточную структуру. И,в данных случаях,следование стандарту приводит к некоторому замедлению кода,а в некоторых случаях,еще и к потере ясности логики (когда в функцию передается структура). |
|||
144
VS-1976
22.05.22
✎
09:29
|
(30) В этой документации указано, что null смысла сравнивать нет, но если после соединения поле цена встанет в null, а потом заменится с помощью функции ЕСТЬNUL на другое значение, то сравнивать вполне себе нормально. Если запись отбрасывается, то это явный баг
|
|||
145
vi0
22.05.22
✎
10:57
|
(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'); |
|||
146
Конструктор1С
22.05.22
✎
10:58
|
(139) топик-то перечитай
|
|||
147
vi0
22.05.22
✎
10:59
|
(143) "следование стандарту приводит к некоторому замедлению кода"
хорошее уточнение - "к некоторому" там обращение к базам данных погасит подобные микрооптимизации |
|||
148
Выпрь
22.05.22
✎
11:05
|
(145) с регулярками ты это конечно пошутил
|
|||
149
vi0
22.05.22
✎
11:07
|
(148) а что не так? если регулярка сложная
|
|||
150
Выпрь
22.05.22
✎
11:10
|
(149) если он чуть сложнее примера будет, то хрен ты ее так запишешь, что читабельно было
|
|||
151
vi0
22.05.22
✎
11:15
|
(150) а в чем проблема?
|
|||
152
Выпрь
22.05.22
✎
11:17
|
(151) проблема в ьом что читабельности не добавит ни капли
|
|||
153
Выпрь
22.05.22
✎
11:17
|
Регулярки они такие как ни риши получается ж.
|
|||
154
vi0
22.05.22
✎
11:18
|
(153) какие то общие слова
|
|||
155
Выпрь
22.05.22
✎
11:20
|
Те пока ты последовательно можешь их читать то разницы никакой нет, что в строчку, что в столбец. А если там всякие если начинаются то ничего не помогает
|
|||
156
vi0
22.05.22
✎
11:26
|
вот пример. главное прокомментировать хорошо
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 |
|||
157
Конструктор1С
22.05.22
✎
11:27
|
(143) ты что-то путаешь
|
|||
158
Выпрь
22.05.22
✎
11:28
|
(156) и что это проще читать?
Можно сходу сказать о чем оно? |
|||
159
Конструктор1С
22.05.22
✎
11:35
|
(155) зря ты так думаешь. В функциональном программировании код пишется почти как регулярных выражениях, вкладываются одно условие в другое. Но форматирвание сильно упрощает жизнь. Погугли, например, примеры кода на языке Clojure
|
|||
160
Конструктор1С
22.05.22
✎
11:37
|
Но можно и поближе посмотреть. Попробуй сложный sql запрос в одну строку вытянуть, сразу понятность запроса в труху
|
|||
161
vi0
22.05.22
✎
11:44
|
(158) я тебе передаю суть, что разбитие по строкам, отступы и комментарии добавляют читабельности, а ты за конкретный пример цепляешься
там тоже кооментарии абстрактные типа // Capture group #1 напиши туда конкретику и все будет понятно |
|||
162
Выпрь
22.05.22
✎
11:56
|
(159) написание через точку с новой строки - это совсем другое.
Странно что ты разницы не видишь |
|||
163
Конструктор1С
22.05.22
✎
12:00
|
(162) что совсем другое? Я бы сказал так - размазывание кода в одну устроку убъет абсолютно любой код
|
|||
164
Конструктор1С
22.05.22
✎
12:01
|
+а кто тебе сказал, что в функциональных языках точка с запятой в конце строки?
|
|||
165
Конструктор1С
22.05.22
✎
12:02
|
||||
166
Гений 1С
гуру
22.05.22
✎
17:21
|
(144) не, бага нет, у меня код возвращал NULL, а он отбрасывался в ГДЕ
|
|||
167
VS-1976
22.05.22
✎
18:16
|
(166) если в где было без естьnull(), тогда левое соединение заменяется законно на внутреннее, что несколько ускоряет запрос, в противном случае, левое должно оставаться и зазвращать 100% записей из таблицы ТБ
|
|||
168
VS-1976
22.05.22
✎
18:18
|
(167) заменяется законно на внутренее , если есть условие сравнения без естьnull
|
|||
169
Said_We
23.05.22
✎
00:22
|
(168) В примере в (0) вообще соединение не нужно. Выше писал почему.
|
|||
170
Said_We
23.05.22
✎
00:24
|
(166) в (168) + к (169) писал в (47).
|
|||
171
Said_We
23.05.22
✎
11:00
|
Про именование переменных, это вечный спор о вечном. :-)
|
|||
172
Гений 1С
гуру
23.05.22
✎
12:13
|
(169) и почему же?
|
|||
173
Said_We
23.05.22
✎
12:59
|
(172) ответ в (40), (46), (47).
|
|||
174
Said_We
23.05.22
✎
13:55
|
(172) Я ответил на вопрос: Почему?
|
|||
175
vi0
23.05.22
✎
15:15
|
(171) это про комменты
А именование +- регламентировано |
|||
176
Said_We
23.05.22
✎
15:33
|
(175) Комментарии не нужны, если код написан нормально. Собственно идеально когда код написан так, что бы комментировать не было необходимости.
Если имена переменных очень понятны, но они километровые, то логика алгоритма теряется за длиной имен переменных. Поэтому должен быть консенсус. По запросам ещё проще. Конструкции стандартные, количество операторов наверное меньше чем команд в ассемблере. Комментировать особо не чего. Тут практически не алгоритм, а описание результата. Если таблиц штук пять или меньше и связи простые, то фиолетово какие будут имена у таблиц. FROM всегда где-то рядом. Можно просто т1, т2... Если есть вложенная одинокая таблица в подзапросе, то внутри можно просто т. По умолчанию предлагает ВложенныйЗапрос, но проще просто т. Т.е. Выбрать ИмяТаблицы1.Поле1 ,ИмяТаблицы2.Поле1 ИЗ ИмяТаблицы1 как ИмяТаблицы1 ,(выбрать т.Поле1 из КакаяТоТаблица как т где т.Поле1 = 0) как ИмяТаблицы2 Я про алиас "т" таблицы "КакаяТоТаблица", который внутри подзапроса. |
|||
177
Kassern
23.05.22
✎
15:38
|
(176) "По запросам ещё проще" - ага, когда 100500 таблиц во менеджерах временных таблиц. А потом еще всякие вложенные таблицы внутри вложенных таблиц и все обезличенные - ммм какая красота, как же все легко читается и понятно, что автор хотел в этом запросе)
|
|||
178
Said_We
23.05.22
✎
15:42
|
(177) Прикинь и это только в 1С такой треш. А знаешь почему? SQL стандарт 10-ти летней давности. + Недостаток функционала в тех же функциях. Математические функции только добавили.
Это я к чему. Ко скольким физическим таблицам обращается этот километровый запрос? |
|||
179
vi0
23.05.22
✎
15:44
|
(176) я не спрашивал, нужны ли комментарии
|
|||
180
Said_We
23.05.22
✎
16:05
|
(179) Извини, но я так понял твой пост.
|
|||
181
Конструктор1С
23.05.22
✎
16:06
|
(178) трэш в запросах, потому что 1сники повадились напичкивать запросы сложной логикой, где только можно. Коллективная такая болезнь
|
|||
182
Said_We
23.05.22
✎
16:10
|
(181) Какая ещё сложная логика? А чем речь?
|
|||
183
Конструктор1С
23.05.22
✎
16:13
|
(182) ну когда начинаются невнятные условия соединений, портянки выбор когда... тогда..., переливания данных через пятнадцать временных таблиц
|
|||
184
Конструктор1С
23.05.22
✎
16:16
|
вот такое авно в том или ином виде растеклось по 100500 модулям в типовых конфигурациях
Сумма * ВЫБОР КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18) ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118) ТОГДА 0.18 КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10) ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110) ТОГДА 0.1 КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0) ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.БезНДС) ТОГДА 0 КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20) ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120) ТОГДА 0.2 ИНАЧЕ 0 КОНЕЦ КАК СуммаНДС |
|||
185
Kassern
23.05.22
✎
16:17
|
(184) это вы еще лесенку с родителями не скинули))
|
|||
186
vi0
23.05.22
✎
16:18
|
да, болезнь называется "я такой крутой программист, что смог всю логику запихать в запрос"
|
|||
187
Said_We
23.05.22
✎
16:20
|
(183) "портянки выбор когда... тогда..." - Для простых конструкций есть короткая конструкция IIF(Условие, РезультатЕслиИстина, РезультатЕслиЛожь), но только не в 1С.
"переливания данных через пятнадцать временных таблиц" - это как правило из-за отсутствия оконных функций, а так же простых функций без временных таблиц RANK(), DENSE_RANK(), ROW_NUMBER(). Самый простой пример итог нарастающим итогом с группировкой. Пишется в одну строку, а так как в 1С нет оконных функций, то надо таблицу саму с собой соединять, что-то считать... В общем километр бесполезного кода. (186) Нет. Подобные задачи не в 1С тоже решают с помощью SQL запроса, но выглядит это всё компактно и понятно. |
|||
188
vi0
23.05.22
✎
16:22
|
(187) какие "подобные"? я не говорил ни о каких то конкретных задачах
|
|||
189
Конструктор1С
23.05.22
✎
16:24
|
(187) так про то и речь, что 1сный SQL чрезвычайно ограниченный. На кой в него пихать то, что гораздо проще сделать на встроенном языке? Код на встроенном языке обладает несравнимо большей гибкостью, чем запросы. Ну получи ты данные из табличек, соедини их, а потом во встроенном языке прогони через код
|
|||
190
Said_We
23.05.22
✎
16:25
|
(188) Любые подобные. Не решает же 1С какие-то задачи, которые решает только 1С. Скорее наоборот - 1С не решает многих задач, которые решают не на 1С. Собственно так можно не только про 1С говорить. Всегда есть какой-то аналогичный инструмент, который может решать аналогичные задачи.
|
|||
191
Said_We
23.05.22
✎
16:27
|
(189) Запрос даст в общем случае более быстрый результат. Бывают какие-то исключения, но это как правило задачки олимпиадные, которые в промышленном коде не решают. :-)
|
|||
192
Конструктор1С
23.05.22
✎
16:29
|
(191) например, что запрос может ускорить в (184)?
|
|||
193
vi0
23.05.22
✎
16:29
|
(190) вообще слово "подобные" подразумевает сравнение
я говорю о сотруднике который пишет цикл или условие в одну строку или пихает всю логику в запрос, только лишь по той причине что в этот момент он чуствует себя тру-програмистом |
|||
194
Said_We
23.05.22
✎
16:29
|
Мне таки интересно Серёжа ответит на мой вопрос в (174).
"(172) Я ответил на вопрос: Почему?" |
|||
195
vi0
23.05.22
✎
16:30
|
(191) общий случай - называется преждевременной оптимизацией, если ты понимаешь о чем я
|
|||
196
Конструктор1С
23.05.22
✎
16:36
|
(195) вот да, преждевременная оптимизация - отдельный вид зла. Который не намного лучше дублирования в коде. А уродливые запросы это прям комбо. Тут и дублирование (одно и то же растаскивается по множеству запросов), и преждевременная оптимизация
|
|||
197
Said_We
23.05.22
✎
16:36
|
(192) Цепонуть сразу короткую таблицу, в которой напротив каждой ставки уже свой коэффициент: 0, 0.1, 0.18, 0.2...
По скорости внутреннее соединение короткой таблицы, будет быстро, а копипаста минимум. Что бы не было по "100500 модулям в типовых конфигурациях". Таблица же статическая. При запуске создал и юзай везде. |
|||
198
Said_We
23.05.22
✎
16:39
|
При добавлении новой ставки в 17%, достаточно при запуске поправить создание таблицы. Код будет статичный.
|
|||
199
Конструктор1С
23.05.22
✎
16:45
|
(197) ну реальность-то таковая, что в тысяче запросов накрошили "выбор когда тогда" с конкретными ставками
(198) так не сделали этого сразу же. Поэтому добавление двух несчастных значений в перечисление привело к исправлениям в 100500 запросам. Самое интересное, отдельной таблички со ставками тут и не нужно было. Достаточно было при обходе выборки звать функцию вычисления ставки НДС. Если СКД, то в вычисляемых полях ту же функцию дёргать |
|||
200
Конструктор1С
23.05.22
✎
16:46
|
Вот, запросная наркомания из типовой. Запрос сам себя дублирует
ВЫБРАТЬ ВЫБОР КОГДА КорректировкаПоступленияТовары.КоличествоДоИзменения >= КорректировкаПоступленияТовары.Количество ТОГДА &ИсправляемыйДокументПоступления ИНАЧЕ &СчетФактура КОНЕЦ КАК СчетФактура, &ИсправляемыйДокументПоступления КАК Партия, &Склад КАК Склад, ЗНАЧЕНИЕ(Перечисление.ВидыЦенностей.ПустаяСсылка) КАК ВидЦенности, КорректировкаПоступленияТовары.Номенклатура КАК Номенклатура, КорректировкаПоступленияТовары.СтавкаНДС КАК СтавкаНДС, КорректировкаПоступленияТовары.Количество - КорректировкаПоступленияТовары.КоличествоДоИзменения КАК Количество, ВЫБОР КОГДА НЕ КорректировкаПоступленияТовары.Ссылка.СуммаВключаетНДС ТОГДА КорректировкаПоступленияТовары.Сумма + КорректировкаПоступленияТовары.СуммаНДС - (КорректировкаПоступленияТовары.СуммаДоИзменения + КорректировкаПоступленияТовары.СуммаНДСДоИзменения) ИНАЧЕ КорректировкаПоступленияТовары.Сумма - КорректировкаПоступленияТовары.СуммаДоИзменения КОНЕЦ КАК Стоимость, КорректировкаПоступленияТовары.СчетУчета КАК СчетУчета, КорректировкаПоступленияТовары.СчетУчетаНДС КАК СчетУчетаНДС, КорректировкаПоступленияТовары.Ссылка.Дата КАК Период, КорректировкаПоступленияТовары.Ссылка.Организация КАК Организация, КорректировкаПоступленияТовары.НомерСтроки КАК НомерСтроки, КорректировкаПоступленияТовары.Ссылка КАК Регистратор, ЛОЖЬ КАК НоваяСтрока, ВЫБОР КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС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 И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый |
|||
201
Said_We
23.05.22
✎
16:50
|
(199) СКД это в основном вывод результата в читабельном виде с динамическими группировками и колонками. Не нужно в СКД совать логику расчетную, которая не в отчет.
Не сделал, так зачем было править при добавлении ставки путем добавлении везде - сразу переписать. Это проблемы проектирования конфигураций 1С. Особенно в последнее время. Создадут кучу реквизитов, а потом удаляют и создают новые такие же. Не знать заранее что в нашей стране ставка НДС может меняться хоть каждый день... Ну как бы не первый раз они меняются и не последний. |
|||
202
Выпрь
23.05.22
✎
16:51
|
(200) а как надо было?
|
|||
203
Конструктор1С
23.05.22
✎
16:51
|
(201) проблема со ставками НДС не была бы проблемой, если бы 1сники не вычисляли её в запросе
|
|||
204
Выпрь
23.05.22
✎
16:52
|
(201) справочник все равно не поможет ибо жесткая привязка колонок к ставкам
|
|||
205
Said_We
23.05.22
✎
16:52
|
(200) Я так понимаю разница тут:
В выбрать ЛОЖЬ КАК НоваяСтрока, и в условии И КорректировкаПоступленияТовары.КоличествоДоИзменения = 0 И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый (202) Выбор когда добавь и радуйся. |
|||
206
Kassern
23.05.22
✎
16:52
|
(202) вангую КорректировкаПоступленияТовары.СтавкаНДС.Множитель и все - без всяких выбор когда))
|
|||
207
Конструктор1С
23.05.22
✎
16:53
|
(202) простейшим запросов выбрать данные из ТЧ, потом обойти в цикле, делая вычисления. Код стал бы и короче, и намного читабельнее. Самое главное, его не пришлось бы перепахивать при появлении новых ставок НДС
|
|||
208
Конструктор1С
23.05.22
✎
16:55
|
(205) во-во-во! Отдельный ребус найти разницу в этих двух почти одинаковых запросах. Отдельная удача не допустить ошибку при их доработке...
|
|||
209
Said_We
23.05.22
✎
16:59
|
(207) Не проще. Если этот код при проведении, то вот эти туды-сюды данных ооооочень медленно.
И зачем вычислять, если можно просто соединить и получить нужный коэффициент сразу. Вопрос только в отсутствии таблицы, построенной по статическим данным "Перечисление.СтавкаНДС". Создать служебный РС строить его при запуске 1С и не жужжать. |
|||
210
shuhard
23.05.22
✎
17:01
|
(207) для типовой это сомнительные плюсы
|
|||
211
Конструктор1С
23.05.22
✎
17:02
|
(209) а зачем туды-сюды? Один раз получил данные запросом, и шлифуй их в коде. Один фиг ты притащишь эти данные на сервер, чтобы запихать в наборы записей
>>И зачем вычислять Вот и у меня вопрос. Зачем делать вычисления в запросе? Они уродливые и приводят к дублированию |
|||
212
Said_We
23.05.22
✎
17:02
|
"Строить при запуске 1С" - имеется ввиду при необходимости. При обновлении, например, когда это необходимо.
|
|||
213
Said_We
23.05.22
✎
17:03
|
Мне таки интересно Серёжа ответит на мой вопрос в (174).
Звучал он примерно так: "(172) Я ответил на вопрос: Почему?". |
|||
214
Конструктор1С
23.05.22
✎
17:05
|
(210) это так кажется, оттого что слаще брюквы ничего не едовал, краше типового кода ничего не видовал. К сожалению, копаться в дерьмовом и задублированном коде настолько привычно для нашего брата 1сника, что давно стало обыденностью
|
|||
215
СвинТуз
23.05.22
✎
18:31
|
(0)
Хорошо когда о причине введения функции ЕстьNULL() задумываешься не после собеседования, а в результате тестирования своего запроса. Опыт ценен. Лучше поздно (с несколькими сертификатами), чем никогда. Казалось бы парадокс "NULL <> NULL", но с другой стороны отсутствие значения в разных физических таблицах дает один и тот же NULL. И приравнивать их это терять физический смысл. Ввели эту функцию, что бы разработчик обозначил пустые значения. |
|||
216
СвинТуз
23.05.22
✎
18:33
|
(0)
Убивать за такие запросы надо ))) Шутка. Не рационально. |
|||
217
СвинТуз
23.05.22
✎
18:40
|
Если "Характеристика" это измерение, то еще интереснее. )
Если оно не используется, то зачем в итоговую таблицу выбирать? Если используется активно, то ... . Если реквизит, то видимо другое дело. Короче я в шоке ))). Вникать не хочется в чужую кухню. Удачи Серега. |
|||
218
СвинТуз
23.05.22
✎
18:43
|
Да нет поспешил вроде норм. Конец дня.
Но все равно я бы по другому написал. Все мы разные. (217) взад беру. (216) оставлю Типа мое мнение ) Которое не имеет смысла ) |
|||
219
СвинТуз
23.05.22
✎
18:45
|
Яркий пример что сертификаты ничего не гарантирую )
|
|||
220
Гений 1С
гуру
23.05.22
✎
21:06
|
(218) Перфекционист что ли? НЕ люблю перфекционистов, они убогие стандарты 1с-разработки пишут.
|
|||
221
Said_We
23.05.22
✎
23:43
|
(220) Мне таки интересно Серёжа ответит на мой вопрос в (174).
Звучал он примерно так: "(172) Я ответил на вопрос: Почему?". Уже чисто спортивный интерес. |
|||
222
ДедМорроз
24.05.22
✎
00:00
|
Если кто-то говорит,что в 1с сложные запросы,то пусть чистый sql посмотрит,где хранимые процедуры - вот где внсело и интересно,когда те же "модули",но внутри sql.
|
|||
223
vi0
24.05.22
✎
01:20
|
(222) а для чего смотреть некие абстрактные процедуры? Если смотреть то процедуры конкретные, в конкретных условиях разработки
|
|||
224
Гений 1С
гуру
24.05.22
✎
07:48
|
(221) сформулируй вопрос целиком. Если ты считаешь, что IN лучше чем JOIN, то мы на разных сторонах силы. ОК?
|
|||
225
СвинТуз
24.05.22
✎
09:14
|
(220)
Норм. Не обиделся. Всегда потом можно деньги на оптимизации взять. Кто-то костыли ставит. Кто-то снимает. Так и зарабатываем. Некоторые любят посидеть подождать пока запрос отработает ) Особенно если почасовка идет. |
|||
226
Said_We
24.05.22
✎
13:06
|
(224) У тебя в IN всего два значения и этот IN в параметрах виртуальной таблицы.
Можешь написать не IN а "Условие1" ИЛИ "Условие2". Опа, и нет никакого IN. А у тебя две выборки из одного источника данных, да ещё и левое соединение потом. Ты соединяешь таблицу саму с собой, при этом таблица используется как есть. Т.е. одно дело ты в таблице нашел МАКС или МИН или ещё что и потом соединяешь уже преобразованную таблицу с исходной таблицей. А другое дело просто саму исходную таблицу саму с собой - в этом нет никакого смысла. Она у тебя и при первой выборки уже есть. |
|||
227
Гений 1С
гуру
25.05.22
✎
12:37
|
(199) там они молятся на то, чтобы все вычисления были в запросах. поэтому я и не уважаю стандарты 1С-совместимо. Это не практическое руководство, а религиозное
|
|||
228
Гений 1С
гуру
25.05.22
✎
12:39
|
(194) таки сформулируй вопрос целиком, я запутался в твоих цикличных ссылках
|
|||
229
Said_We
25.05.22
✎
14:42
|
(228) Чего его там формулировать. Зачем левое соединение таблицы самой с собой?
|
|||
230
Галахад
гуру
25.05.22
✎
14:49
|
(227) Это в каком стандарте описано?
|
|||
231
Конструктор1С
25.05.22
✎
15:35
|
(227) бред же. Ты стандарты даже не читал
|
|||
232
Конструктор1С
25.05.22
✎
15:41
|
из стандартов, касательно твоих болячек в (0)
Псевдонимы источников данных в запросах Псевдоним источника данных должен быть осмысленным, чтобы было понятным его назначение в данном контексте. Требования к псевдонимам источников схожи с требованиями к именам переменных в коде. псевдонимы следует образовывать от терминов предметной области таким образом, чтобы было понятно, как источник данных будет использоваться в запросе; псевдонимы следует образовывать путем удаления пробелов между словами. При этом каждое слово в имени пишется с прописной буквы (например, ТоварыНаСкладах). Предлоги и местоимения из одной буквы также пишутся прописными буквами; псевдонимы запрещается начинать с подчеркивания; псевдонимы не должны состоять из одного символа. |
|||
233
Гений 1С
гуру
25.05.22
✎
17:58
|
(232) а из двух можно, ггг? ну что за бред, что за иллюзии в голове этих писателей стандартов?
|
|||
234
Конструктор1С
25.05.22
✎
18:28
|
(233) бред это твой код, а в стандартах все нормально. Что, стандарт задевает твои говнокодерские привычки?
|
|||
235
mikecool
25.05.22
✎
18:31
|
у меня привычка - передаваемую ТЗ как параметр алиасить как Т
ибо такой запрос(на выборку из параметра) обычно пишу руками, привычка - ибо не сразу понял , где в конструкторе этот механизм )) |
|||
236
Said_We
25.05.22
✎
18:34
|
(228) И.... ? Опять я не сформулировал вопрос что ли?
|
|||
237
Гений 1С
гуру
25.05.22
✎
20:15
|
(226) какой такой один источник? там две таблицы с разными видами цен.
Да, можно использовать: РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен) Но там надо не просто макс или мин цену определить, а иметь для расчета цену ВидЦенБ (от нее расчитывается новая цена) и сравинвать с ценой ВидЦен. То, что ты предлагаешь, может и будет работать, но мне кажется, оно сложнее и для проектирования и для осознания тем, кто будет этот код смотреть. Но если ты считаешь что нет, будь добр, сделай рефакторинг этого запроса на: РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен) |
|||
238
Said_We
26.05.22
✎
03:04
|
(237) В (47) же написал уже.
|
|||
239
Said_We
26.05.22
✎
11:54
|
(237) "Но там надо не просто макс или мин цену определить" - а где вообще макс или мин цена?
|
|||
240
Гений 1С
гуру
26.05.22
✎
12:03
|
(238) э нет, дядя, ты напиши весь запрос, как минимум на СГРУППИРОВАТЬ ты уже попал. Не думаю, что твоя экономия на соединить дала тебе какой-то выигрыш. Весь запрос будет монструозным, в отличии от моего, а выигрыша по производительности не будет, план запроса будет ужасным.
|
|||
241
СвинТуз
26.05.22
✎
12:50
|
Побаловался для практики )
"ВЫБРАТЬ | ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура, | ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика, | ЦеныНоменклатурыСрезПоследних.Цена КАК Цена |ПОМЕСТИТЬ НовыеЦены |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура, | ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика, | ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена, | ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения |ПОМЕСТИТЬ БазовыеЦены |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | БазовыеЦены.Номенклатура КАК Номенклатура, | БазовыеЦены.Характеристика КАК Характеристика, | БазовыеЦены.БазоваяЦена КАК БазоваяЦена, | БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения, | ЕстьNULL(НовыеЦены.Цена,0) КАК Цена |ИЗ | БазовыеЦены КАК БазовыеЦены | ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены | ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура | И БазовыеЦены.Характеристика = НовыеЦены.Характеристика |ГДЕ | ЕстьNULL(НовыеЦены.Цена,0) <> &НоваяЦена" |
|||
242
СвинТуз
26.05.22
✎
12:52
|
Можно еще запросы 1 и 2 переставить и выбирать только присутствующие пары Номенклатура + Характеристика из полученной таблицы предвосхищая левое соединение,
но очень похоже что экономии не будет. |
|||
243
СвинТуз
26.05.22
✎
12:54
|
"ВЫБРАТЬ
| ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура, | ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика, | ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена, | ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения |ПОМЕСТИТЬ БазовыеЦены |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура, | ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика, | ЦеныНоменклатурыСрезПоследних.Цена КАК Цена |ПОМЕСТИТЬ НовыеЦены |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних( | &Дата, | ВидЦены = &ВидЦены | И (Номенклатура, Характеристика) В | (ВЫБРАТЬ РАЗЛИЧНЫЕ | БазовыеЦены.Номенклатура КАК Номенклатура, | БазовыеЦены.Характеристика КАК Характеристика | ИЗ | БазовыеЦены КАК БазовыеЦены)) КАК ЦеныНоменклатурыСрезПоследних |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | БазовыеЦены.Номенклатура КАК Номенклатура, | БазовыеЦены.Характеристика КАК Характеристика, | БазовыеЦены.БазоваяЦена КАК БазоваяЦена, | БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения, | ЕСТЬNULL(НовыеЦены.Цена, 0) КАК Цена |ИЗ | БазовыеЦены КАК БазовыеЦены | ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены | ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура | И БазовыеЦены.Характеристика = НовыеЦены.Характеристика |ГДЕ | ЕСТЬNULL(НовыеЦены.Цена, 0) <> &НоваяЦена" |
|||
244
СвинТуз
26.05.22
✎
12:55
|
&НоваяЦена КАК НоваяЦена,
Смысла не имеет. Если только не используется дальше. Проще при переборе выборки подставить куда надо константу единую для всей выборки. |
|||
245
СвинТуз
26.05.22
✎
12:57
|
Возможно есть смысл из-за того при последнем варианте будет задействован первичный индекс.
Ну да не важно )))) |
|||
246
Said_We
26.05.22
✎
14:08
|
(240) Ты же даже не пробовал.
|
|||
247
Said_We
26.05.22
✎
14:14
|
(0) Почему нет связи по "ЕдиницаИзмерения"?
В общем случае одна и та же номенклатура с ценой за килограмм и за центнер, упаковка и коробка 10 шт, и т.д. Или в вашем случае у номенклатуры всегда одна "ЕдиницаИзмерения"? А вдруг кто-то двойника штук сделает? |
|||
248
Said_We
26.05.22
✎
14:27
|
(240) Для затравки....
Запрос по характеристикам |
|||
249
Конструктор1С
26.05.22
✎
15:36
|
(240) не-а. Твой план запроса будет плохим, а его отработает оптимально
|
|||
250
Конструктор1С
26.05.22
✎
15:45
|
+(249) не гарантированно, но с большой долей вероятности будет плохим... Про это на ИТС написано, который ты не читал
https://its.1c.ru/db/v8std/content/655/hdoc 1.1. При написании запросов не следует использовать соединения с вложенными запросами. Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с вложенными запросами, то его следует переписать с использованием временных таблиц (не важно с какой стороны соединения находится вложенный запрос), кроме случая, когда вложенный запрос сканирует мало записей ... Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединяемых выборок представляет собой вложенный запрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса. |
|||
251
Said_We
26.05.22
✎
19:23
|
И слился....
|
|||
252
Гений 1С
гуру
26.05.22
✎
21:00
|
(246) а смысл пробовать, если очевидно, что выйдет хуже. Поэтому ты и не пишешь хотя бы примерный текст запроса, что понимаешь, что у этого Франкенштейна будут "ужасные зубы"
|
|||
253
Гений 1С
гуру
26.05.22
✎
21:01
|
(247) в нашем случае не сделают.
|
|||
254
Гений 1С
гуру
26.05.22
✎
21:02
|
(250) дружок, а где ты у меня вложенный запрос увидал? гггг
|
|||
255
alarm2020
26.05.22
✎
21:04
|
(254) Справа от левой таблицы и слева от правой )))
|
|||
256
Гений 1С
гуру
26.05.22
✎
21:08
|
(255) не гони
|
|||
257
alarm2020
26.05.22
✎
21:09
|
(256) Срез последних - это не таблица, это запрос
|
|||
258
Said_We
26.05.22
✎
21:18
|
(253) В ссылку в (248) зайди. Может что-то не очевидное увидишь.
|
|||
259
Злопчинский
26.05.22
✎
21:45
|
"Не волнуйтесь, если что-то не работает. Если бы всё работало, вас бы уволили."
|
|||
260
Конструктор1С
27.05.22
✎
06:18
|
(254) открою тебе страшную тайну: все виртуальные таблицы в запросах 1с по-факту являются вложенными запросами. Стыдно гуриям такое не знать
|
|||
261
Said_We
27.05.22
✎
10:28
|
(252) "Поэтому ты и не пишешь хотя бы примерный текст запроса" - написан примерный текст запроса ещё в (47).
|
|||
262
Гений 1С
гуру
27.05.22
✎
12:05
|
(261) это только декларация намерений. ггг..
|
|||
263
Гений 1С
гуру
27.05.22
✎
12:05
|
(260) вложенные запросы это то, что находится в операторе IN
|
|||
264
Выпрь
27.05.22
✎
12:06
|
(263) не только
|
|||
265
bolobol
27.05.22
✎
12:19
|
Оператор IN не ошибается, если используется выборка из ВТ без условий, поэтому где-то когда-то был рекомендован к использованию. А в случае замены ИЛИ - прям обязан быть использованным
|
|||
266
bolobol
27.05.22
✎
12:20
|
А виртуальные таблицы - это запрос с неизвестным объёмом результата
|
|||
267
Конструктор1С
27.05.22
✎
12:26
|
(263) не пиши ересь
|
|||
268
Конструктор1С
27.05.22
✎
12:29
|
Смотрю, кризис вайти неслабо тебя накрыл, раз элементарные вещи за столько лет не изучил
|
|||
269
alarm2020
27.05.22
✎
13:56
|
(263) Вложенный запрос - это запрос внутри запроса
|
|||
270
ДедМорроз
28.05.22
✎
16:22
|
Виртуальная таблица - это запрос с группировкой,соответственно,с одной стороны,система не знает результат,с другой,для получения первой записи его нужно выполнить целиком,то есть аналог временной таблицы будет.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |