skmdeveloperПотом подумал. Может лучше хранить данные в таблице, где каждое поле это узел. Структура полей примерно такая:
1. Уникальный числовой идентификатор (тип serial)
2. Идентификатор родительского элемента.
3. Имя узла
4. Данные (если есть)


Зачем так делать? Концептуально, единицей первичного учёта у тебя является GUI форма, а не узел. Сам по себе узел не имеет никакого смысла для приложения, так зачем его вырывать из контекста, писать код, который будет собирать кусочки формы воедино, бороться с провалом производительности, поддерживать целостность данных? Зачем?

Исторически БД поддерживали только простые типы данных - строки, числа, даты и т.п.. Чтобы реализовать модель сложного объекта в реляционной БД, приходилось выполнять его декомпозицию. Например, чтобы строить индексы по некоторым атрибутам объекта, иметь удобный доступ к их значениям как в выражениях, так и в построителях GUI, навешивать ограничения целостности. Сейчас многие системы понимают XML, так что в некоторых случаях объекты можно хранить единым XML документом. При необходимости СУБД может делать декомпозицию этого XML документа на несколько таблиц.

skmdeveloper,
если хорошо работает, то пусть так и работает. Пока не вижу смысла менять. Для работы XML есть много API, в том числе и в SQL. Про PostgreSQL не знаю, в ORACLE для хранения XML можно прозрачно для SQL запросов создать структурированное хранилище сообразно новым потребностям приложений БД.

Может быть у тебя ещё какие то тайные требования есть?

skmdeveloperВ Qt есть классы для его разборки, ничего со стороны использовать не приходится.

Я бы удивился обратному. В продвижение XML столько бабла вбухали, что теперь он поддерживается везде и всюду.

skmdeveloperПридумывать собственный формат глупо.

А всё равно придумывают. Тут вона в БД поле BER кодированное (стандарт OSI). Оно конечно места поменьше занимает чем XML, что в данном случае крайне существенно, но парсер хороший уже два года как сделать не могут.