From f761d49124ad981a0d2c1943e1436c2f95749294 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Wed, 8 Oct 2025 16:50:08 +0300 Subject: [PATCH] =?utf8?q?KEKS=20=D0=B8=201NF?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 полей или реально вложенных в качестве значения других элементов. -- 2.52.0