如何在关系数据库中保留图形数据结构？
发布时间：2020-12-12 16:34:06 所属栏目：MsSql教程 来源：网络整理
导读：我考虑创建一个Vertices表和一个Edges表,但是在内存中构建图形并遍历子图需要大量的查找？我想避免过多的数据库读取.还有什么其他方式坚持图表吗？ 旁注：我听说过Neo4j,但我的问题是在标准数据库中如何在概念上表示图形.我对某些NoSQL解决方案(如mongodb)开
|
我考虑创建一个Vertices表和一个Edges表,但是在内存中构建图形并遍历子图需要大量的查找？我想避免过多的数据库读取.还有什么其他方式坚持图表吗？
旁注：我听说过Neo4j,但我的问题是在标准数据库中如何在概念上表示图形.我对某些NoSQL解决方案(如mongodb)开放. 解决方法不幸的答案是：你的考虑是完全正确的.您必须在一个表中存储Nodes / Vertices,以及引用FromNode和ToNode的Edges将图形数据结构转换为关系数据结构.而且你也是对的,这样做最终会在大量的查找中出现,因为你不能将它分成子图,可以一次查询.您必须遍历从节点到边缘到节点到边缘到节点…等等(递归地,SQL正在使用集合).重点是… 关系,面向图形,面向对象,基于文档的是不同类型的满足不同要求的数据结构.这就是它所有的一切,为什么这么多不同的NoSQL数据库(大多数是简单的文档存储)出现了,因为以关系方式组织Bigdata根本没有意义. 备选1 – 面向图形的数据库 但也有面向图形的NoSQL数据库,这使得图形数据模型成为像OrientDB这样的一流公民,我现在在玩一点点.关于它的好处是,尽管它将数据作为一个图形持续存在,但它仍然可以以关系或甚至面向对象或面向文档的方式使用(即通过使用简单的旧SQL进行查询).尽管如此,Traversing the graph是从中获取数据的最佳方式. 备选方案2 – 使用内存中的图形 当涉及快速路由时,诸如Graphhopper之类的路由框架在内存中构建完整的图(数十亿个节点).因为Graphhopper使用其GraphStore的MemoryMapped实现,甚至可以在只有一些MB内存的Android设备上工作.完整的图形在启动时从数据库读入记忆体,然后在那里进行路由,因此您无需查找数据库. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |