比如文档系统中一本手册的版本号,是创建成点,还是作为手册节点的属性?
比如账户间交易的详情(金额、时间等),是创建成点,还是作为边上的属性?
比如论坛中的回帖,是创建成点,还是作为边上的属性?
。。。
我大概知道这些要根据具体业务来决定,但是具体要怎么决定呢?大神能给说细点儿么?多谢啦
申请证书
证书详情
ID | |
产品 | |
状态 | |
核数 | |
申请天数 | |
审批时间 | |
过期时间 | |
MAC地址 | |
申请理由 | |
审核信息 |
用户邮箱:
当前未申请证书.
Certificate | Issued at | Valid until | Serial No. | File |
---|
Serial No. | Valid until | File |
---|
Not having one? Apply now! >>>
ProductName | CreateTime | ID | Price | File |
---|
ProductName | CreateTime | ID | Price | File |
---|
No Invoice
登录
还没有嬴图账号?立即 注册
已经有嬴图账号了?立即 登录 !
返回 登录
比如文档系统中一本手册的版本号,是创建成点,还是作为手册节点的属性?
比如账户间交易的详情(金额、时间等),是创建成点,还是作为边上的属性?
比如论坛中的回帖,是创建成点,还是作为边上的属性?
。。。
我大概知道这些要根据具体业务来决定,但是具体要怎么决定呢?大神能给说细点儿么?多谢啦
1 个回答
这个问题非常的关键,无论是对业务人员还是技术人员。
你的问题有3个,但是在回答你的问题之前,我们要先了解图数据库本身的特点。
所有的图数据库设计都源自于图论的一些基础理论。里面有个最基础也是最重要的概念跟图的数据模型有关: Simple Graph vs. Multi-graph,中文即:简单图 vs. 多边图。
简单图即单边图,所谓单边图,指的是两个顶点之间只能最多存在1条边!
而多边图则不存在这个限制。
然而,基于单边图还是多边图而构建的不同的图数据库在这里就产生了剧烈的分化!
单边图上面很少支持边的过滤,一般都通过对顶点及其属性过滤来实现业务逻辑。
多边图则可以支持点或边上面的属性过滤。
可以认为支持多边图模式的图数据库更灵活,而且它可以向下(后)兼容单边图。
Ultipa Graph DB就是支持的多边图的典范。并且可以通过边过滤来实现快速的遍历时动态剪枝加速。
现在我们开始回答你的第2个问题,交易(trx),理论上最天然地适合构建为边,两个账户或卡之间可以存在多笔转账交易,即多条边,交易的属性(金额、时间、设备ID等)天然的适合作为边的属性。
你的第1个问题,某个文档的多个版本号,即可以作为多个顶点的属性,也可以作为多条边的属性而存在。至于哪种模式更适合,取决于具体的业务需求和查询逻辑,在此不再展开。
第3个问题,回帖,单边图模式下一般是创建为新的顶点,多边图模式下,作为新的边(的属性)是okay的。
最后,我们用一张示意图来展示单边图vs.多边图,希望大家能有所收获: