图数据库：2 关联数据的存储选择

      我们生活在互联的世界中。为了发展进步，我们需要理解并影响所处的网络。

2.1 关系型数据库缺少联系

     数十年来，开发者试图使用关系型数据库处理关联的、半结构化的数据集。关系型数据库设计之初是为了处理纸质表格以及表格化结构---有些方面关系型数据库做得非常好---它们试图对这种实际中的特殊联系进行建模。然而讽刺的是，关系型数据库在处理联系上做得却并不好。

     下图展示了一个以客户为中心的、事务型应用程序存储顾客订单的关系模式。

     这种模式的设计对该应用程序产生了很大影响，使有些查询非常简单，而有些异常困难。

• 表连接增加了偶发复杂性，使得业务数据与外键元数据混杂起来。
• 外键约束增加了额外的开发与维护成本，而目的仅仅是为了让数据库工作。
• 带有空值列的稀疏表在代码中需要额外检查，尽管模式本身提供了相关支持。
• 仅因为想查看客户买了什么就需要好几个昂贵的连接。
• 反向查询代价更高。查询”某个客户买了哪些商品？“比查询”有哪些客户买了某个商品？“的代价相对要低，而这是推荐系统的基础。对于这样的需求，可以引入索引，然而即使引入索引，随着递归程度的增加，诸如”有哪些买这个商品的客户也买了那个商品？“这样的递归问题的查询代价变得异常高昂。

2.2 NoSQL数据库也缺少联系

    大多数NoSQL数据库---无论是键值数据库、文档数据库，还是基于列的数据库---存储的都是无关联的文档/值/列，因此很难将它们用于关联数据和图。

    对于这些数据库来说，一种广为认知的添加联系的策略是在某个聚合数据中嵌入另一个聚合数据标识符，即添加外键。然而这需要在应用层连接聚合数据，其代价极速增加。

     这种方案还有另一个弱点。由于没有反向指针（外部聚合引用的指针当然不是自反的），数据库丧失了运行其他有趣的查询的能力。比如上图，想要知道是谁买了某种商品就是一个代价高昂的操作。想要回答这类问题，还要暴力的获得。

2.3 图数据库拥抱联系

    作为用户，我们推断实体之间的语义相关性，但数据模型与数据库本身却忽视了这些关联。为了弥补这一点，我们的应用程序必须着手创建一个扁平的、无连接的数据之外的网络，然后再处理那些由反规范化存储导致的缓慢查询和延迟写入。

六度分割