clonalman
2012-11-18 20:22
2012-11-18 09:27 "@banq"的内容
是啊,我看到你在业务建模:BoundedContext(有界上下文)举例Product中也说明这个问题。模型复杂多变,带来的持久也不方便,一旦改变起来修改维护也不方便。图库Neo4J实际是一个很好的对象化持久方式,至少熨平了一些过去对象和关 ...

如果再进一步延伸,部件之间除了数量特征的约束之外,还需要生产装配顺序、损耗工时,加上生产工艺、工作中心、资源约束,相信就不是Neo4J所能解决的,还是得回归关系数据库

banq
2012-11-18 21:44
2012-11-18 20:22 "@clonalman"的内容
相信就不是Neo4J所能解决的,还是得回归关系数据库 ...

能否详细解释之?

clonalman
2012-11-20 23:31
2012-11-18 21:44 "@banq"的内容
能否详细解释之? ...

主要是关系的深度,图数据库(Neo4J)只支持一层关系,而关系数据库可支持无限层次,不知道理解的对不对?

Neo4J怎么表达Relationship之间的Releationship?我看Neo4J相关的例子都是一层的扁平化的结构,所以这种数据库应用范围还是很有限的,哪天有空我找个把Product的例子再拓展一下,看Neo4J能不能存储与遍历?

banq
2012-11-21 15:36
2012-11-20 23:31 "@clonalman"的内容
图数据库(Neo4J)只支持一层关系,而关系数据库可支持无限层次 ...

参考这篇文章:

Modeling a multilevel index in neoj4

clonalman
2012-11-21 19:34
2012-11-21 15:36 "@banq"的内容
Modeling a multilevel index in neoj4。 ...

---------------

START root=node:node_auto_index(name = 'Root')

MATCH

commonPath=root-[:`2011`]->()-[:`01`]->commonRootEnd,

startPath=commonRootEnd-[:`01`]->startLeaf,

endPath=commonRootEnd-[:`03`]->endLeaf,

valuePath=startLeaf-[:NEXT*0..]->middle-[:NEXT*0..]->endLeaf,

values=middle-[:VALUE]->event

RETURN event.name

ORDER BY event.name ASC

------

我只是粗略看了一下这个图数据库,能解析一下这个Index吗?

感觉这个查询特性不是我想要的特性。

startLeaf-[:NEXT*0..]->middle-[:NEXT*0..]->endLeaf

startLeaf、middle、endLeaf都是node

[:NEXT*0..]之间的relationship对吧,我不想要node之间的遍历查询,

而是想看到[:NEXT*0..]之间的遍历导航关系。

一层Relationship1:ALeaf->[:NEXT*0..]->BLeaf (这是node之间)

二层Relationship2:“ALeaf->[:NEXT*0..]->BLeaf ”与“CLeaf->[:NEXT*0..]->DLeaf ”(这是relationship之间)

请问:使用图数据库如何存储和遍历relationship2?

[该贴被clonalman于2012-11-22 01:54修改过]

banq
2012-11-22 07:54
2012-11-21 19:34 "@clonalman"的内容
使用图数据库如何存储和遍历relationship2 ...

我是这样想,不知有没有道理:图库实际是一种树形结构,树分枝和叶,是否可以用枝Node来表达一个relation,将relation包装成Node,类似包装成对象一样,它是否是在用另外一种方式来表达关系呢?而如果采取关系数据库Join方式来表达关系,虽然灵活强大,但是丧失了可伸缩性,图库这种方式可伸缩性很强,可以不断线性增加服务器提高处理能力。

clonalman
2012-11-22 12:47
2012-11-22 07:54 "@banq"的内容
我是这样想,不知有没有道理:图库实际是一种树形结构,树分枝和叶,是否可以用枝Node来表达一个relation,将relation包装成Node,类似包装成对象一样,它是否是在用另外一种方式来表达关系呢?而如果采取关系数据库Join方式来表 ...

是的,Relation退化为Node,这个图数据库与关系数据已经没什么区别了,其实我想要的不是结点之间的关系,而已一个结点于一个数之间的关系或两棵树之间的相互关系.

举个例子,我们的手机,它的配件可能是机身、电池、SD卡、耳机、手机帖膜等,一般来说,机身、电池是必须件,SD卡、耳机、手机帖膜是可选件,如果我机身的ROM只有1G,装完操作系统、常用软件就什么空间,这时候SD卡可能就变成必须件了,当我的手机是16G的,SD卡就是可选件; 用树来表达手机的组成那是相当给力,但是如何表达node的property对整个树结构的影响了?(SD卡由可选件变为必须件,手机的产品BOM已经发生了变化了,这只是一个简单的例子,实际业务就没这么简单)

banq
2012-11-23 07:55
2012-11-22 12:47 "@clonalman"的内容
如何表达node的property对整个树结构的影响了 ...

存储property适合使用Ke-value的NoSQL,或列族如HBase等,不同NoSQL适合不同的数据结构,不能象关系数据库打包天下了。

clonalman
2012-11-24 10:29
2012-11-23 07:55 "@banq"的内容
存储property适合使用Ke-value的NoSQL,或列族如HBase等,不同NoSQL适合不同的数据结构,不能象关系数据库打包天下了。 ...

节点、节点属性与整棵树的关系,两棵树之间的关系,图数据库如何描述存储?

banq
2012-11-24 10:51
2012-11-24 10:29 "@clonalman"的内容
节点、节点属性与整棵树的关系,两棵树之间的关系 ...

我是这样思考,你看对不对,因为NOSQL多样化,我的思考边界就不限定在一个图库或Key-value思考,而是从数据或者说对象高度去思考。

Property属性是值,其有Key,这个Key和图库的Node的Key是一样的值,比如:

Class Product{

Long Id; //Key

Collection<Property> props;

Catalog cat;

}

我们可以把 Long Id; 和 Collection<Property> props;保存到Key-value数据库;而把Long Id; Catalog cat;保存到Neo4J图库。

clonalman
2012-11-24 11:03
2012-11-24 10:51 "@banq"的内容
Property属性是值,其有Key,这个Key和图库的Node的Key是一样的值,比如:Class Product{ Long Id; //Key Collection props; Catalog ca ...

Key-value存储,图数据去查询?

Product下的某个具体属性特征,影响到了Product对某些Part的选取或装配,这个关系又怎么定义?

banq
2012-11-25 15:12
2012-11-24 11:03 "@clonalman"的内容
图数据去查询 ...

这两个问题我感觉应该是让领域层去完成,比如查询通过仓储层,比如Product 的Id为888,那么到图库查Key为888的,再到HBase查key也为888的,两者在仓储组装还原成领域模型Product即可。

关于“某个具体特征影响到了Product某个具体Part的装配”,这个涉及到一个复杂的模型多样化,还涉及到这些特征是否经过业务活动以后的特征,比较复杂,至于如何表达Product和某个Part之间的这种非高聚合,而是一种非常松耦合的关系,可以专门设立一个Node或Key-value对来表达它们之间的关系,比如Key为888, Value为Part的Id。

我比较认同文中一种隐式观点,那就是,只有需要事务时才需要RDBMS,而且这种事务还不是高频的,否则又不合算了。

也就是说,RDBMS的核心竞争力只是它的ACID事务而已,可靠性,其他都可以被替代。只是可能我们太过重依赖它,以至于发现没有它好像什么都不行,其实这是一种习惯培养的错觉。另外,我觉得也只有试图去除RDBMS,我们才能真正发现软件表达业务的价值,就像孩子必须离开父母才能找到自己的价值一样。

[该贴被banq于2012-11-25 17:23修改过]

clonalman
2012-12-09 07:04
2012-11-25 15:12 "@banq"的内容
RDBMS的核心竞争力只是它的ACID事务而已,可靠性,其他都可以被替代 ...

如果核心竞争力是事务,其他类型数据库早早晚晚都会赶上的,RDBMS核心竞争力应该是其“简洁”的存储结构,假设存在一个工具可能让其数据与其他非关系数据库相互转化,非关系数据库的数据绝对转化并存储到关系数据库上,而关系数据库的数据并不一定能转化并存储其他非关系数据库

猜你喜欢
2Go