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 上一页 1 2