KEKS и 1NF

https://en.wikipedia.org/wiki/1NF
Столяров в 5e68d1f880d17b6464fb862a7ea2791440ad8fba много раз повторяет
мантру о том, что форматы данных где есть рекурсивные вложенные
структуры -- не имеют права на существование, типа XML, JSON, MIME. Типа
first normal form нормализации должно хватать для всего.

Я тут, в отличии от студентов начальных курсов, вообще не в теме. Я
слышал про нормализацию данных в СУБД, но никогда ничего не читал по
этому поводу. Что наверное крайне плохо говорит обо мне, как о
специалисте.

Видя многочисленные примеры ненормализованного представления данных и
должного нормализованного -- я просто понимаю, что и так делал всегда
всё должным образом нормализованным. Ну в преобладающем большинстве
случаев уж точно.

Насколько понял, то 1NF нормализованная форма вот такой структуры:

    {
        "foo": 123,
        "bar": {"op": 1, "po": 2},
        "baz": [4, 5, 6],
    }

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

     0 | map | -   | -
     1 | str | foo | 0
     2 | str | bar | 0
     3 | str | baz | 0
     4 | int | 123 | 1
     5 | lst | -   | 2
     6 | str | op  | 5
     7 | int | 1   | 6
     8 | str | op  | 5
     9 | int | 2   | 8
    10 | lst | -   | 3
    11 | int | 4   | 10
    12 | int | 5   | 10
    13 | int | 6   | 10

Это вроде бы довольно легко преобразовать в Python/Go в "изначальную"
структуру. Само кодирование бы было просто последовательностью строк
таблицы.

По сути -- всё как и сейчас в KEKS, вот только нет ссылок на другие
элементы. Если отталкиваться от того, что кодирование детерминированно:
ключи map-ов отсортированы, строки таблицы не могут идти в произвольном
порядке, то с наличием явного EOC "атома"/типа, от ссылок в последнем
столбце можно избавиться, так как они автоматом могут быть поняты и
вычислены. А это уже превращается буквально в текущий формат KEKS.

Или я совсем ничего не понял что Столяров подразумевал, так как ничего
не читал про теорию БД. Либо мой KEKS и так уже является
удовлетворительным форматом. Судя по всему, наезды то именно на форматы,
где значением элемента может быть рекурсивно очередная структура. Ну
типа вот читаешь про MIME и видишь его форматы заголовков перед частями,
оцениваешь насколько это сложно делать. Не сложно. Пока не попадаешь на
предложение, говорящее что элементом MIME part-а может быть другой MIME,
что сразу означает куда более сложную структуру данных в памяти и в
целом работу. Хотя ведь в XML мы тоже же можем "атомы" в виде тэгов
читать последовательно, так и чем же значение моего списка от LIST до
EOC отличается от значения куда встроены данные?

Мой Си декодер KEKS, вроде как уже точно, хранит декодированные данные в
1NF нормализованном виде. Это просто массив атомарных элементов, где они
могут ссылаться друг на друга. В зависимости от типа элемента
(list/map), это в более высокоуровневом языке, можно бы было сделать
list или map/dict. KEKS по сути является сериализацией 1NF таблицы
items, с оптимизацией по убиранию ссылок (последнего столбца таблицы) за
счёт более строгих правил по упорядочиванию элементов таблицы, ну и
наличии элемента явно сигнализирующим о конце list/map. Но в KEKS не
было аналогов ANY полей или реально вложенных в качестве значения других
элементов.