分层数据模型的替代方案

Question

问题域

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

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

当前解决方案

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

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

所有实体(图像,图像特征,分析对象,解决方案,附加数据)都是相应类的实例(如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"),然后通过ID从全局存储中获取解决方案特征的实际C++对象.

这个问题

所以我的主要问题是

• 使用RDBMS是我描述的问题的合适解决方案,还是不值得,有更好的方法来组织我的应用程序中的信息？

如果RDBMS没问题,我会很感激有关使用RDBMS和关系方法存储C++对象关系的任何建议.

Answer 1

根据您对可扩展和灵活模型的要求，我不推荐 RDBMS。

1. 每当您更改数据模型时，您都必须更改数据库模式，这可能涉及比代码更改更多的工作。
2. 数据库查询的任何问题只有在运行时才会发现。这会对维护成本产生很大影响。

我强烈建议使用标准 C++ OO 编程和 STL。

1. 您可以利用封装来确保正确完成任何数据更改，并更新相关对象和索引。
2. 您可以使用STL对数据建立高效的索引
3. 您可以创建外观来轻松获取信息，而不必访问多个对象/集合。这将是一次性的工作
4. 您可以制作单元测试用例以确保正确性（与使用数据库进行单元测试相比要简单得多）
5. 您可以利用多态性来构建不同类型的对象、不同类型的分析等

所有这些都是非常基本的点，但我认为如果您改进当前的解决方案而不是寻找基于数据库的解决方案，您的努力将得到最好的利用。