关系数据库中不同对象的图（实现类似的接口）

Question

所以我在思考涉及将对象序列化到关系数据库的某些问题。

假设您有 N 个不同的对象，它们都实现了某个接口（就此而言是一个有向图接口。它们提供诸如 getIncomingNodes() 、 getOutgoingNodes() 之类的方法）。

如果每个这样的对象在关系数据库中都有对应的表， 将这种有向图序列化到关系数据库的最佳实践是什么？

假设 N 很小，（在我的例子中，N=3）我将所有可能的链接分解为一个单独的表。 例如，从对象 x 指向 y 的链接表将类似于：

tbl_links_X_Y {
int X_id
int Y_id
}

问题是，您得到 N^2 个这样的表 - 效率不高，而且将来可能难以扩展到 N+1 个对象。

有什么模式可以解决这个问题吗？ （即使不涉及关系数据库，我也很乐意听到......）

谢谢！o

Answer 1

您也可以轻松地将对象的类（表名）存储在连接表中。

tbl_links_X_Y {
int X_id
int Y_id
enum {user, customer, product} X_type
enum {user, customer, product} Y_type
}

您只需将其包含在 where 或 join 子句中即可。

我猜这不是一个严格的关系数据库，因为你不能（？）使用/强制外键约束。

Answer 2

您还可以“强制”您的图表遵循关系模型：即

表格图{ 整数顶点， varchar 边缘列表 }

edgelist 可以是一个基于分隔符的字符串：例如 {2,10},{3,12},{4,13} 等，其中条目是 {incident vertex,weight}
这样，表中的行数将是 O(n) 而不是 O(n^2)

然后，当您的应用程序读取图表并执行一些操作时，您必须在内存中构建图表并执行相同操作。

Answer 3

所以最近我遇到了一个 NoSQL 框架调用 OrientDB
数据库引擎正好处理了这个问题。 它是一个graph database，具有执行SQL 查询和延迟加载另一个对象指向的对象（例如相邻顶点）的能力。

剩下的一件事是将这个框架的性能与传统 SQL 数据库的性能进行比较。 （当然，我必须考虑在传统 SQL 数据库中从原始响应构造对象到查询所需的时间。）

一旦我得到这个比较的结果，我会把它们贴在这里。