仓储上升为架构是一个难题

11-03-21 SpeedVan
复杂的sql条件是死穴,看来还是逐个定制来得方便。例如有些人获取某些超复杂条件的实体集,虽然可以用一个条件类来实现常用的条件封装,但感觉自己还是有点力不从心。有谁可以说说sql如何全面用一个类来代替呢?(关键点是多个实体,状态属性不一样,如何覆盖?如同key-value的列不一样,所带来的问题)

如同NoSQL的DHT,查询能力十分有限啊,在网上看到与SQLDB混合使用以得到解决。

其实我怀疑,是不是sql用多了,于是我就不想处理一致性问题了。(有些东西感觉理想当然的时候,就需要怀疑了)

axgle
2011-03-21 16:52
抛开自然语言的特性,oo只是关系理论的一个子集.换言之,关系理论是oo的"超集".superset:)

例如: "你怀疑nosql."
oo的表示: "你.怀疑.nosql"--这是"中缀表达式".
而"前缀表达式"是一个怀疑函数:"怀疑(你,nosql)"
虽然怀疑函数没有oo表达式"自然",但本质上没有区别.
oo只是关系理论的一个子集,而且是真子集:)

SpeedVan
2011-03-21 17:09
这意思是指?

banq
2011-03-21 18:43
复杂的sql就是复杂的业务模型,用specification模式实现。
不要试图在技术层面找sql和领域模型对应关系,本是出发点两个角度矛盾的东西。只有从业务需求重新出发。这就是模型驱动开发区别于数据库驱动开发本质。

axgle
2011-03-21 20:57
比如,设计模式通常都是用类图表示的.但设计模式并非只能用类图表示,很多人都用c或java或其他语言来表示.因为设计模式是思想,可以有多种表现方式.下面,看我怎么用er图来展示设计模式,同时让你体会到,ER图远比类图优雅的多.我们以"策略模式"作为例子:

这是经典的"策略模式的ER图",非常简洁直观:


以下是传统的UML类图,其右下角(A,B,C)只是上面ER图里的三条record(三行数据).



规则为:表名(关系名)对应类名(class),一行记录对应一个对象(object),主键(primary_key)对应object_id,外键(foreign_key)对应对象引用(object reference).
ER图是比类图更加具有普适性的图.因为基于类的OO语言所表达的关系,只是关系理论的一个子集,而且是"真子集".理论上,任何设计模式都可以用er图表示出来,欢迎思考尝试.

SpeedVan
2011-03-21 23:47
2011年03月21日 18:43 "banq"的内容
specification模式 ...


噢NO,知识盲点,我去补补先,N本书就没说这个。

主要原因在于找出实体集时,不知如何用方法来描述,如“找出大于100岁的人”,“找出所有女性”,“找出上年注册的,而且关注人数大于0的用户”···这些是因具体业务而定的,那么也就是说泛型仓储在这样的环境下相当难以实行。有种做着做着的跑去做nosql的感觉了···除非存在一个约定查询,或者在其内部,实现检索。

查数据好查,查实体不好查。想把所有仓储都合并成一个,取单个可以通过类名+类id方式获取,取一个集合就比较困难了。回归自然的想法:我就面对着一个仓储,我对着仓储说“给我id为1000的用户”,然后仓储把id为1000的用户从里面叫出来了;我对着仓储说“给我id>2000的用户”,然后仓储就从里面把id>2000的用户叫出来给我了。若果加入“女的”“未婚的”等条件,何其复杂。而明显是我们说出条件,仓储去思考如何组织实体集——咋感觉就像一个nosql和sqldb的组合呢?

猜你喜欢