为什么要使用图数据库（下）：设计开发和应用场景

我们在图数据库上篇讲了在功能设计和code上的区别，但那不是重点了。这篇会重点阐述： 设计开发和应用场景。 

图数据库Neo4j和关系数据库的最大区别是：Neo4j属于 Nosql数据库，而是否使用SQL，是表象，其本质在于:

在无模型设计的情况下，自然可以不受模型的制约，例如 MongoDB 也是这样（不受制约，但也不能任性，还是要有设计）。

例如：

我们想管理员工的信息，不只管理基本信息，还需要记录员工更多的工作情况。我们简单的画出一些关系图，如下：

从部门到分组，到分组成员，每个员工有参与的项目，有作为某类数据库的owner，或者是参加了哪类俱乐部，或者是在哪个职场。

如果在关系数据库中，我们要怎么做？ 

首先我们要分析出模型，通常如下，我们要设计一套表：

表1：部门和分组表（有层级关系）
表2：员工基础信息表，并且归属到某个分组
表3：项目表，整理出“项目”的一些属性作为字段，记录到项目表中
表4：数据库类型表
表5：员工和数据库的关系表，记录哪些员工是某类数据库owner
表6：俱乐部表
表7：员工和俱乐部的关系表，记录哪些员工参加哪个数据库

我们要详细分析这些表需要的字段，然后建表、插入数据。这没有问题，我们是可以实现的，虽然在一些关联查询上会复杂些。

但，这些关系可能会经常性的变化，增加、修改、或者删除。

例如：

1.    某天我们又增加一个虚拟的组织结构，比如 “某某委员会”。

处理办法 ： 新增加两张表，一张表记录委员会的信息，一张表记录委员会和员工的关系。  

2.    发现某个项目有特殊的属性需要记录（这是原来分析没有的）。

处理办法： 为项目表增加字段。   

3.    某位员工离职，我们要查询出这位员工所有的关系，并进行替换或者删除。

处理办法 ：你需要写procedure，查询所有的有关系的表，并返回，如果新增了表（例如上面的委员会表），你要记得在procedure中增加扫描的逻辑。

这些变化都是需要走DB版本实现的。因为在“有模型”的 设计模式 下，我们必须要先修改模型，才能装入数据，并且修改和模型有关的程序。

//

图数据库中的实现

//

那么在图数据库中，如何实现呢？  

在图数据库中，我们是不需要把这个图形分析、化解成表的模型， 我们要做的就是把这个图按它本身的样子记录下来（基本上是这样，细节上可能会有些经验性东西，先忽略）  

1）把上图的每一个元素都创建为一个节点，并分配标签（标签不需要建表）。
2）建立节点之间的关系， 关系是可以有类型和属性的。
3）新增的变化，只需要创建新的节点和关系就可以了（不需要再建新的表或者修改已有表的结构）。
4）我们不需要一个开始就把整个关系图都全部分析清楚，去建立一个大而全的模型。比如上图只是一个部门的，后续我们还可以扩大到整个公司。比如有些项目工作会涉及到其它的多个子公司、部门，会有新的属性。

我们通过脚本创建了上图中的节点和关系，并查询整个图如下：

可以看到图数据中所表达的图，和上面需求分析的图。基本是一致的。（注意上图中我们也定义了关系的类型）

在图数据库设计、实施中的方式应该是： 所见即所得 。不再需要做“有模型设计”。

目前，图数据库的数据，常常是从关系数据库导入。而关系数据库中是对原来场景分析建模后的设计。建议不要以关系数据库已有的模型去设计图数据库，这可能无法发挥出图数据库的最大作用。

下面看看需求有变化，新增了“某某委员会” 的情况，不需要修改模型，只是需要新增节点和关系。

create (n:COMMITTEE{ID:26,NAME:'某某委员会'});
MATCH(a:EMPLOYEE{ID:9} ),(b:COMMITTEE{ID:26} ) CREATE (a)-[r:owner]->(b);
MATCH(a:EMPLOYEE{ID:7} ),(b:COMMITTEE{ID:26} ) CREATE (a)-[r:owner]->(b);
MATCH(a:EMPLOYEE{ID:12} ),(b:COMMITTEE{ID:26} ) CREATE (a)-[r:owner]->(b);
MATCH(a:EMPLOYEE{ID:13} ),(b:COMMITTEE{ID:26} ) CREATE (a)-[r:owner]->(b);

下面是一些查询的例子：

1.    查询出从部门到COMMITTEE有关的关系路径：

MATCH p=(a:DEPARTMENT{ID:1} )-[*]->(b:COMMITTEE) return p;

2.    查询和某个员工有关的关系路径：

MATCH p=(a:DEPARTMENT{ID:1} )-[*]->(b:EMPLOYEE{ID:16} )-[*]->(c) return p;

3.    查看“云数据库开发项目”有哪些同事参与：

MATCH p=(a:DEPARTMENT{ID:1} )-[*]->(b:PROJECT) where b.NAME='云数据库开发项目' return p;

//

图数据库的适用场景

//

当然，也要识别哪些是不适合图数据库的场景：图数据库(Neo4j)并不能像关系数据库那样，很容易的实现统计，报表分析。（虽然Neo4j也有一些aggregate函数）  

图数据库(Neo4j)还是比较适合读多写少的场景。 在写入或者删除时候，需要维护关系的链接指针。因此大量而频繁的写操作，在性能上是一个考验。

图数据库(Neo4j)要和其它数据库做数据同步的话，方法还不是很多，可能需要自己写同步程序实现。  

所以Neo4j也给出了一些适合的 常见应用场景 ，如:

关于平安云：

诞生于平安集团，由平安科技自主研发的平安云已经建设成为金融行业内最大的云平台，涵盖平安集团95%以上的业务公司，支撑80%的业务系统投产。并以金融为起点，深度服务于金融、医疗、智慧城市、房产、汽车五大生态圈，作为平安服务的综合输出平台为全行业提供IaaS（基础设施服务）、PaaS（通用平台服务）、SaaS（软件应用服务）全栈服务。

热门

《平安科技与教育考试院合作》

平安云，助力教育智能化

奖项

《 年度价值云企业 》

打造银行数字化转型解决方案

新闻

《2018金融云服务商排行榜》

平安云荣登榜首