使用图形数据库模型数据

本文章所处阶段为个人阅读图数据库的相关书籍资料
以下图片来自图书 Graph database 第二版 ,O'Reilly图书，Ian Robinson,Jim Webber & Emil Eifrem著

这里不再赘述图形数据库blahblah的优点，还有怎么安装部署。
在很多文章中，都提到图数据库的一项用途：处理社会关系。比如

image.png

上图应该算是图库最基础的应用，因为现实生活中的社会关系并不是对称的，而如果要用关系数据库或者常见的kv cloumn nosql来实现，则一个朋友关系就需要至少2个字段，friend of与 friend by。如果要查询“朋友的朋友”，或“朋友的朋友的朋友”，那么数据库的算法复杂度则会直线上升，直到任务由于查询时间过长而无法完成。
并且，假设一对或单向的朋友关系（意识到自己把别人当朋友，别人却把自己不当回事）结束，那么使用传统的存储方式，你还需要删除上文中类似friend by字段中的内容。

现在再上面应用的基础上，增加一点难度，或者说让例子能更贴近广大程序员的业务场景。

image.png

在这张图中，包含了3张表的内容（用户、订单与货物）
同时也表现出一种“大同”的景象，在图库中，数据就是一个一个node，彼此都是完全平等的。所以我们需要用一个字段来表示某个node的角色，比如在neo4j中系统指定了label这个属性，而dgraph并没有指定，需要我们自行设置，这里需要注意。
另外需要指出这个most_recent关系，它和其他关系相比是不固定的，如果有了新订单，可以马上将这个most recent关系指向新的node。
而且订单可能失效，可能被删除。当这个node被删除后，相关的关系都会自动被清除。这也是图数据库的一大灵活性，如果你是一个经验不足的程序员，在设计业务关系时是很容易遗漏这些应该被清除的数据，而图数据库则能自动帮你清理不要的“垃圾”

图书在这里顺便提到，现在的图库大多对数据节点node的字段有做一些类型处理，比如存储地理信息，而不是说一个node就是简单的kv键值对集合。在dgraph中，你还可以对node的某key执行不同的索引策略。比如某key的类型是string，你可以对其应用hash索引，也可以进行全量索引。
但抛开这些细枝末节的内容，我们需要把握一点，关系是图库中的一等公民，而且你应更抽象地理解这个“关系”，这里的关系不仅仅是node与node之间，node本身的各个自定义的kv也可以认为是“关系”。

Chapter 3 Data Modeling with Graphs
1，相比传统数据库，图库的modeling更“白板友好”
2，一个node可以有多个label
3，注意设置node与node之间的关系方向，没有变幻方向的关系，而应明确的指出是从node A 指向node B
4，不光node可以具有属性（properties，可以理解为就是node存储的kv set），关系也是可以有属性的，这样就给实际应用提供更多meta 数据
接下来图书介绍的是如何利用上面这些简单的原则来创建图库model，需要使用sql语言，图书中介绍的是cypher，而dgraph使用的是GraphQL

先放一些书中介绍cypher时的图片

image.png

image.png

image.png

cross-domain models

image.png

这张图片是关于莎士比亚文学相关的内容，通过 图中关系线的类型，可以看到这跨越了3个 domain。
所以这也是关系为什么重要的原因，关系可以帮助我们建立一个domian，也可以帮助我们将不同的domain之间的数据进行关联。

职业生涯

image.png

演员的表演记录

image.png

发送邮件并抄送

image.png

可以注意到，图中的关系，既可是一种动作，也可以是一个属性
而数据节点node，既可以是动作的主体，也可以是动作的客体

影评家写的影评

image.png

某电视节目的timeline tree（记录一系列事件）

image.png

剧集之间的关系

image.png

再次强调关系需要方向

不同的关系应对不同的需求

image.png

这个人通过ADDRESS关系拥有2个地址，这两个地址分别应用于两种不同的场景