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