database-design - 为重构图而优化的有向图模式

我有一个应用程序，其模型最好表示为有向图。给定节点，无论是叶节点还是分支点，都可以有多个父节点和多个子节点，但所有“顶级”父节点都是虚拟根节点的子节点。因此，Neo4J 或其他一些图形数据库可能适合后端。警告：我对图形数据库知之甚少，但话又说回来，这就是我问的原因。

环顾四周，大多数图形模式似乎都针对在大部分静态图中快速搜索大数据（例如，数百万或数十亿个节点）进行了优化。

在我的应用程序中，尽管可能有很多用户，但每个用户都有自己的图，由（很可能）数千个而不是数百万个节点组成，但最常见的操作是重构图。例如添加子节点；从其父节点之一中删除子节点；向子节点添加新的父节点，添加和删除兄弟节点，等等。

当然，搜索当前图也很重要，但我担心重构的成本。如果我不需要，请解释原因。

我的问题是传统的图形数据库是否适合这样的应用程序，以及是否某些可能比其他的图形重构更好。或者是否在更理论的层面上对此进行了处理，或者甚至可能有用于管理这样一个系统的软件库。对于层次结构（其中子节点可能只有一个父节点），我遇到过这样的事情，但对于有向图却没有。

标签： database-designschemadirected-graph

从与技术无关的角度出发，您无需担心重构，因为操作应该是线性的。

让我们使用下图进行分析，其中C=Customer, O=Order, P=Product, I=Item.

分析添加O4到图中的步骤，我们有

所以创建一个节点是一个单一的操作（创建节点），创建一个关系至少需要 3 个步骤（创建关系，更新开始/结束节点）。

根据这个关于 Neo4j 如何在内部存储数据的链接，我们可以确定上面的示例根本不是很昂贵。而且，正如您所指出的，随后的搜索/遍历很便宜。

如果您要考虑一种新兴技术，例如Apache AGE，答案就不太明显了。这是因为 AGE 将节点和关系数据存储在表中，并将 Cypher 转换为子查询。因此，您可能需要考虑存在的任何索引的次要成本，如果不存在，则成本会随着节点/关系的增长而增长。