图数据库，第2版

第 2 章 存储连接数据的选项 存储连接数据的选项

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我们生活在一个相互联系的世界。为了繁荣和进步，我们需要了解并影响我们周围的联系网络。

当今的技术如何应对连接数据的挑战？在本章中，我们将探讨关系数据库和聚合 NOSQL 存储如何管理图形和连接数据，并将它们的性能与图形数据库的性能进行比较。对于有兴趣探索 NOSQL 主题的读者，附录 A介绍了四种主要类型的 NOSQL 数据库。

关系数据库缺乏关系

几十年来，开发人员一直试图在关系数据库中容纳相互连接的半结构化数据集。但是，关系数据库最初的设计目的是对纸质表格和表格结构进行编码--这一点关系数据库做得非常出色--而当试图对现实世界中出现的临时、特殊关系进行建模时，关系数据库却举步维艰。具有讽刺意味的是，关系数据库处理关系的能力很差。

关系数据库中确实存在关系，但只是在建模时作为连接表的一种手段。在上一章关于连接数据的讨论中，我们提到我们经常需要明确连接实体的关系的语义，并确定它们的权重或强度。而关系型数据则无法做到这一点。更糟糕的是，随着离群数据成倍增加，数据集的整体结构变得越来越复杂、越来越不统一，关系模型就会被庞大的连接表、稀疏的行和大量的空校验逻辑所拖累。连接性的增加在关系世界中转化为连接的增加，这阻碍了性能的提高，并使我们难以根据不断变化的业务需求发展现有的数据库。

图 2-1显示了在以客户为中心的事务型应用程序中存储客户订单的关系模式。

图 2-1. 关系数据库中隐藏着语义关系

应用程序对该模式的设计产生了巨大影响，使一些查询变得非常容易，而另一些查询则更加困难：

• 连接表增加了意外的复杂性；它们混合了业务数据和外键元数据。

• 外键约束增加了额外的开发和维护费用，而这仅仅是为了使数据库正常运行。

• 尽管存在模式，但带有可空列的稀疏表需要在代码中进行特殊检查。

• 仅仅为了了解客户购买了什么，就需要几个昂贵的加盟。

• 互惠 查询的成本更高。与 "哪些客户购买了这种产品？"相比，"客户购买了哪些产品？"的成本相对较低，而 "哪些客户购买了这种产品？"则是推荐系统的基础。我们可以引入索引，但即使有了索引，随着递归程度的增加，诸如 "哪些购买此产品的客户也购买了该产品？"这样的递归问题很快就会变得昂贵得令人望而却步。

关系数据库在高度关联的域中举步维艰。为了了解在关系数据库中执行连接查询的成本，我们将看看社交网络域中一些简单和不太简单的查询。

图 2-2显示了一个用于记录朋友关系的简单连接表。

图 2-2. 在关系数据库中模拟朋友和朋友的朋友

如例 2-1 所示，询问 "谁是鲍勃的朋友？"非常简单。

例 2-1。 鲍勃的朋友

SELECT p1.Person
FROM Person p1 JOIN PersonFriend
  ON PersonFriend.FriendID = p1.ID
JOIN Person p2
  ON PersonFriend.PersonID ...