为什么主流DBMS没有图形功能？

Question

关系数据库经常用于存储各种风格的图形（树，有向图，无向图，......）。

为什么然后没有主要的DBMS（Microsoft，MySql，Oracle，PostgreSQL，SqlLite，只是按字母顺序命名）包括库支持将关系视为图形？

一些理想的功能，例如：

• 约束检查（连通性，非共性，平面性，......）
• 常用功能（最短路径，最小生成树，传递闭包，最大流量/最小切割，集团检测，哈密尔顿/欧拉循环......）
• 提高上述任何一项
的性能所需的辅助数据结构

在数据库之外构建对其中一些内容的支持很复杂，因为（除其他原因外）：

• 这本来就很复杂（图书馆帮忙）
• 许多数据通常支持简短的答案：运行最短路径算法的外部客户端要么对数据库非常“讨厌”，要么需要检索比所需数据量大得多的数据;这两种选择都不利于网络
• 当完整性依赖于图论理论约束时保持完整性需要访问所有建议的更新，因此触发器和从触发器访问现有图库在许多系统中都很复杂
• DBMS存储管理器和优化器具有独特的优势，可以解决辅助数据结构问题，就像索引一样

这不是一个修辞问题，我实际上想知道是否有有趣的技术（或历史）原因。

Answer 1

我曾在一个research group工作过，感兴趣的是在RDF（S）数据的数据库中，它基本上被标记为图形，或三元组[subject，predicate，object]，它们基本上是图形边缘：[sourceNode，edgeLabel，targetNode]。

要问的问题是，要了解问题的难度：您要为标记图构建哪种指数？您拥有以利用常见的“属性”（每个“谓词”是主题的属性，具有对象的值），并相应地索引边缘，因此您可以快速查找“是否有”在值大于18“的人物上称为”hasAge“的边缘。

为了说明，这里有一个简单的方法，它是模式遗忘的（并且与传统数据库研究的方向相反，它非常一致地认为模式好有）。它完全忽略了任何架构信息（this paper提供了有用的上下文）。只需将所有内容存储在三个大表中（s：subject，p：predicate，o：object）：

1. [s，p，o]
2. [p，o，s]
3. [o，s，p]

这三个足以回答任何有效评估任何查询（最多）一个主题，（最多）一个谓词，和（最多）一个对象（即(s, *, *)形式的查询，{{1 }}，(*, p, *)，(*, *, o)，(s, p, *)，(s, *, o)，(*, p, o)）。复杂查询虽然包含许多“路径表达式”（即您描述的数据，您可以找到满足某些条件的某些路径），但每个路径都转换为其中一个（大！）表的自连接，而不是所有这些都是有效的，这是一个问题。

那里，口袋里有一个简单的图形数据库。 ：）

结论，这是积极研究的领域。我不知道目前的艺术水平，但我看到像AllegroGraph这样的产品和其他产品都声称效果非常好。

Answer 2

Oracle支持图形功能（Oracle Locator / Oracle Spatial）和语义Web功能。

Answer 3

我怀疑你的问题包含了自己答案的开头。

对于通用数据库，您列出的常用功能通常根本不需要。是的，图形操作肯定需要它们，但很少用于客户计费。当然，关系数据库可以在表中存储图形，但图形操作超出了我见过的任何SQL版本的能力。

您编写构建对数据库之外的某些内容的支持是复杂的。是的，这就是为什么我们都得到这么多的报酬。但是，将这些内容的支持构建到数据库中会不会那么复杂呢？