Мысли в слух по сериализации в YAML

Когда мы говорим, что существующий механизм сериализации объектов в XML файлы дает на выходе результат слишком громоздкий, чтобы удобно работать с ним в рамках CVS, то имеем ввиду не обилие разметки, а постоянное дублирование служебной информации и зависимых объектов. Можно взять сто контактов и сохранить их в сто отдельных файлов, и в каждом мы найдем: а) подробную структуру бизнес-класса, перечисление всех его полей с типами; б) все объекты, на которые наш контакт содержит ссылки (например папку, куда он входит и т.п.).

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

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

Кроме ссылок, модуль должен содержать минимальный номер структуры базы данных.

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