Непонятный результат запроса

1С v8

, ,

22.09.19

✎

22:46

ВЫБРАТЬ
    ВЫБОР
        КОГДА Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель ЕСТЬ НЕ NULL
            ТОГДА Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель.Родитель.Наименование + "/"
        ИНАЧЕ ""
    КОНЕЦ КАК Поле1,
    ВЫБОР
        КОГДА Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель ЕСТЬ НЕ NULL
            ТОГДА Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель.Наименование + "/"
        ИНАЧЕ ""
    КОНЕЦ КАК Поле2,
    Номенклатура.Ссылка КАК Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура
ГДЕ
    Номенклатура.ПометкаУдаления
    И Номенклатура.ЭтоГруппа
    И Номенклатура.Ссылка = &ссылка

В результате Поле1 = "", а Поле2 = NULL.
Почему так?

1 2S

22.09.19

✎

22:47

Что за жесть

2 H A D G E H O G s

22.09.19

✎

22:51

(0) не делай так

3 Fram

22.09.19

✎

22:51

(0) а разве не очевидно?.. Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель - пустая ссылка, то есть корень справочника.

4 RomanYS

22.09.19

✎

22:51

(0) А что непонятного
Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель - пустая ссылка
Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель.Наименование - NULL

5 John83

22.09.19

✎

22:57

(3) (4) спасибо!
вечерний тупняк

6 Krendel

23.09.19

✎

00:39

(0) Вот это говно код ;-)

7 John83

23.09.19

✎

11:11

(1) (2) (6) что конкретно вам так не понравилось?

8 mkbusiness

23.09.19

✎

11:21

(7) То, что это написали не они.

9 novichok79

23.09.19

✎

11:25

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

10 John83

23.09.19

✎

11:48

(9) в типовой УТ 11 не нашел такого реквизита
да и в любом случае, это "разовая" задачка

11 pudher

23.09.19

✎

11:51

(9) Во как делают реальные посоны https://habr.com/ru/company/lsfusion/blog/468047/

12 CrushBy

23.09.19

✎

14:59

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

13 novichok79

23.09.19

✎

18:19

(12) разве? насколько я знаю, денормализация это когда данные, которые хранятся в таблице 2, на которую есть ссылка в таблице 1, добавляют в таблицу 1, чтобы не вызывать чтение таблицы 2.

14 novichok79

23.09.19

✎

18:20

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

15 CrushBy

23.09.19

✎

20:49

(13) Это чаще используется для индекса, так как накладные расходы на обычный join не очень большие. Но вообще принцип нормализации данных заключается в том, чтобы какие-либо данные хранились в одном месте. И в общем случае денормализацией является любая схема хранения, при которой одни данные могут быть посчитаны на основе других. В частности, каноническое имя группы может быть рассчитано исходя из хранения потомок/родитель.