Альтернатива иерархической модели данных

Проблемная область

Я работаю над довольно большим приложением, в котором используется иерархическая модель данных. Он берет изображения, извлекает особенности изображений и создает объекты анализа поверх них. Таким образом, базовая модель похожа на Объект -(1 :N )-Изображение _Характеристики -(1 :1 )-Изображение. Но один и тот же набор изображений может быть использован для создания нескольких объектов анализа (с разными параметрами ).

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

Текущее решение

Это набросок решения. Стеки представляют собой наборы объектов, стрелки представляют собой указатели (, т. е. элементы изображения ссылаются на свои изображения, но не наоборот ). Некоторые части :изображения, особенности изображения, дополнительные данные могут быть включены в несколько объектов анализа (, поскольку пользователь хочет провести анализ на разных наборах объектов, объединенных по-разному ).

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

Все сущности (изображения, признаки изображения, объекты анализа, решения, дополнительные данные )являются экземплярами соответствующих классов (типа IImage,... ). Почти все части необязательны (, т. е. мы можем захотеть отбросить изображения после того, как получим решение ).

Недостатки текущего решения

1. Навигация по этой структуре болезненна,когда вам нужны соединения, подобные пунктирному на эскизе. Если вам нужно отобразить изображение с парой функций решений сверху, вам сначала нужно выполнить итерацию по объектам анализа, чтобы найти, какие из них основаны на этом изображении, а затем выполнить итерацию по решениям для их отображения.
2. Если для решения 1. вы решите явно хранить точечные ссылки (, т.е. класс изображения будет иметь указатели на функции решения, которые с ним связаны ), вы приложите очень много усилий, чтобы поддерживать согласованность этих указателей и постоянно обновлять ссылки, когда что-то меняется.

Моя идея

Я хотел бы построить более расширяемую (2 )и гибкую (1 )модель данных. Первая идея заключалась в использовании реляционной модели, разделяющей объекты и их отношения. И почему бы не использовать RDBMS здесь -sqlite кажется мне подходящим движком. Таким образом, сложные отношения будут доступны с помощью простых (левых )JOIN в базе данных :псевдокода " images JOIN images_to_image_features JOIN image_features JOIN image_features_to_objects JOIN objects JOIN solutions JOIN solution_features" )и последующего извлечения фактических объектов C++ для функций решения из глобального хранилища по идентификатору.

Вопрос

Итак, мой основной вопрос

• Является ли использование СУБД подходящим решением для описанных мною проблем, или оно того не стоит, и есть лучшие способы организации информации в моем приложении?

Если RDBMS в порядке, я был бы признателен за любые советы по использованию RDBMS и реляционного подхода для хранения отношений объектов C++.