Проблемный домен
Я работаю над довольно большим приложением, в котором используется иерархическая модель данных. Он берет изображения, извлекает особенности изображений и создает объекты анализа поверх них. Таким образом, базовая модель похожа на Object-(1:N)-Image_features-(1:1)-Image. Но один и тот же набор изображений можно использовать для создания нескольких объектов анализа (с разными параметрами).
Тогда объект и изображение могут иметь множество других связанных объектов, например, объект анализа может уточняться дополнительными данными или сложные выводы (решения) могут быть основаны на объекте анализа и других данных.
Текущее решение
Это набросок решения. Стеки представляют собой наборы объектов, стрелки представляют собой указатели (т. е. элементы изображения ссылаются на свои изображения, но не наоборот). Некоторые части: изображения, особенности изображения, дополнительные данные могут быть включены в несколько объектов анализа (поскольку пользователь хочет провести анализ на разных наборах объектов, объединенных по-разному).
Изображения, признаки, дополнительные данные и объекты анализа хранятся в глобальном хранилище (бог-объект). Решения хранятся внутри объектов анализа посредством композиции (и, в свою очередь, содержат признаки решения).
Все объекты (изображения, признаки изображения, объекты анализа, решения, дополнительные данные) являются экземплярами соответствующих классов (например, IImage, ...). Почти все части являются необязательными (например, мы можем отказаться от изображений после того, как у нас будет решение).
Недостатки текущего решения
- Навигация по этой структуре болезненна, когда вам нужны связи, подобные пунктирной на эскизе. Если вам нужно отобразить изображение с парой функций решений сверху, вам сначала нужно выполнить итерацию по объектам анализа, чтобы найти, какие из них основаны на этом изображении, а затем выполнить итерацию по решениям для их отображения.
- Если для решения 1. вы решите явно хранить точечные ссылки (т.е. класс изображения будет иметь указатели на функции решения, которые с ним связаны), вы приложите очень много усилий, чтобы поддерживать согласованность этих указателей и постоянно обновлять ссылки, когда что-то меняется .
Моя идея
Я хотел бы построить более расширяемую (2) и гибкую (1) модель данных. Первая идея заключалась в использовании реляционной модели, разделяющей объекты и их отношения. И почему бы не использовать здесь СУБД - 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++.
