复杂的sql条件是死穴，看来还是逐个定制来得方便。例如有些人获取某些超复杂条件的实体集，虽然可以用一个条件类来实现常用的条件封装，但感觉自己还是有点力不从心。有谁可以说说sql如何全面用一个类来代替呢？（关键点是多个实体，状态属性不一样，如何覆盖？如同key-value的列不一样，所带来的问题）
如同NoSQL的DHT，查询能力十分有限啊，在网上看到与SQLDB混合使用以得到解决。
其实我怀疑，是不是sql用多了，于是我就不想处理一致性问题了。（有些东西感觉理想当然的时候，就需要怀疑了）
抛开自然语言的特性,oo只是关系理论的一个子集.换言之,关系理论是oo的"超集".superset:)
例如: "你怀疑nosql."
oo的表示: "你.怀疑.nosql"--这是"中缀表达式".
而"前缀表达式"是一个怀疑函数:"怀疑(你,nosql)"
虽然怀疑函数没有oo表达式"自然",但本质上没有区别.
oo只是关系理论的一个子集,而且是真子集:)
这意思是指？
复杂的sql就是复杂的业务模型，用specification模式实现。
不要试图在技术层面找sql和领域模型对应关系，本是出发点两个角度矛盾的东西。只有从业务需求重新出发。这就是模型驱动开发区别于数据库驱动开发本质。
比如,设计模式通常都是用类图表示的.但设计模式并非只能用类图表示,很多人都用c或java或其他语言来表示.因为设计模式是思想,可以有多种表现方式.下面,看我怎么用er图来展示设计模式,同时让你体会到,ER图远比类图优雅的多.我们以"策略模式"作为例子:
这是经典的"策略模式的ER图",非常简洁直观:
以下是传统的UML类图,其右下角(A,B,C)只是上面ER图里的三条record(三行数据).
规则为:表名(关系名)对应类名(class),一行记录对应一个对象(object),主键(primary_key)对应object_id,外键(foreign_key)对应对象引用(object reference).
ER图是比类图更加具有普适性的图.因为基于类的OO语言所表达的关系,只是关系理论的一个子集,而且是"真子集".理论上,任何设计模式都可以用er图表示出来,欢迎思考尝试.
噢NO，知识盲点，我去补补先，N本书就没说这个。
主要原因在于找出实体集时，不知如何用方法来描述，如“找出大于100岁的人”，“找出所有女性”，“找出上年注册的，而且关注人数大于0的用户”···这些是因具体业务而定的，那么也就是说泛型仓储在这样的环境下相当难以实行。有种做着做着的跑去做nosql的感觉了···除非存在一个约定查询，或者在其内部，实现检索。
查数据好查，查实体不好查。想把所有仓储都合并成一个，取单个可以通过类名+类id方式获取，取一个集合就比较困难了。回归自然的想法：我就面对着一个仓储，我对着仓储说“给我id为1000的用户”，然后仓储把id为1000的用户从里面叫出来了；我对着仓储说“给我id>2000的用户”，然后仓储就从里面把id>2000的用户叫出来给我了。若果加入“女的”“未婚的”等条件，何其复杂。而明显是我们说出条件，仓储去思考如何组织实体集——咋感觉就像一个nosql和sqldb的组合呢？