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

前端之家收集整理的这篇文章主要介绍了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对象关系的任何建议.

解决方法

我不推荐使用RDBMS,因为您需要一个可扩展和灵活的模型.

>每当您更改数据模型时,您将不得不更改DB模式,并且可能涉及比代码更改更多的工作.
>只有运行时才会发现DB查询的任何问题.这可能与维护成本有很大差异.

我强烈建议使用标准C OO编程与STL.

>您可以使用封装,以确保任何数据更改正确完成,并更新相关对象和索引.
>您可以使用STL在数据上构建高效的索引
>您可以创建立面,轻松获取信息,而不必去多个对象/集合.这将是一次性的工作
>您可以使单元测试用例确保正确性(与使用数据库的单元测试相比,复杂得多)
>可以利用多态来构建不同类型的对象,不同类型的分析等

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

原文链接:https://www.f2er.com/c/113286.html

猜你在找的C&C++相关文章