c – 层次数据模型的替代方案

我正在开发一个相当大的应用程序,它使用分层数据模型.它需要图像,提取图像的特征,并在其上创建分析对象.所以基本的模型就像Object-(1：N)-Image_features-(1：1)-Image.但是可以使用相同的图像集来创建多个分析对象(具有不同的选项).

然后一个对象和图像可以有很多其他连接的对象,像分析对象可以用附加数据或复杂的结论(解决方案)进行细化,可以基于分析对象和其他数据.

当前解决方案

这是解决方案的草图.堆叠表示对象集合,箭头表示指针(即图像特征链接到其图像,但反之亦然).一些部分：图像,图像特征,附加数据可能被包含在多个分析对象中(因为用户想要对不同的对象集进行分析,结果不同).

图像,特征,附加数据和分析对象存储在全局存储(god-object)中.解决方案通过组合(并依次包含解决方案功能)存储在分析对象内.

所有实体(图像,分析对象,解决方案,附加数据)都是相应类的实例(如IImage,…).几乎所有的部件都是可选的(也就是说,我们可能希望在解决方案之后放弃图像).

当前解决方案的缺点

>浏览此结构是痛苦的,当您需要连接,如草图中的虚线.如果您必须在顶部显示几个解决方案功能的图像,则首先必须遍历分析对象,以查找基于此图像的哪些图像,然后迭代解决方案以显示它们.
>如果要解决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”),然后通过ID从全局存储中获取解决方案特征的实际C对象.

问题

所以我的主要问题是

>使用RDBMS是一个适用于我所描述的问题的解决方案,还是不值得,有更好的方式来组织我的应用程序中的信息？

如果RDBMS是好的,我会赞赏使用RDBMS和关系方法来存储C对象关系的任何建议.