该帖已经被评为新手帖
|
|
---|---|
作者 | 正文 |
发表时间:2008-12-23
用hashMap解决多表查询
|
|
返回顶楼 | |
发表时间:2008-12-23
楼主的意思应该是 在做查询的时候 对每种查询情况 都需要使用一个javabean来封装参数。 我想楼主肯定没有深入学习过ibatis,对ibatis的每个查询或其它 db operation只能指定一个参数,但是这个完全可以不用新增多余的bean来封装这些参数(除dto外的bean):使用map 或ibatis的动态查询(<dynamic prepend="set">.......)。
|
|
返回顶楼 | |
发表时间:2008-12-23
icewubin 写道 fight_bird 写道 caipanjin 写道 ...
1.使用ResultMap的select会产生“N+1”的问题,这是我不想像ORM那么处理的原因。 ... 实际项目中很少出现N+1的问题,而是x/N+1的问题,其中x可以理解为每页的记录数,无需担心。 实际项目,如果是延迟加载多张表的话,就是M×(x/N)+1问题,怎么能无需担心呢?表的关系稍微一复杂,再加上页面上的显示元素牵涉的表比较多的话,很容易出性能问题。 刚毕业都是作坊式/学究式的设计手段:n多的表关联一起查询,这里有很多最佳实践的细节问题:表结构优化、业务字典......,这是理论和实践差距,这也是经验的价值所在,你做几个大数据量的项目就明白为什么应该设计成x/N+1结果。 |
|
返回顶楼 | |
发表时间:2008-12-23
这充分说明人是很贱的,给你限制死了,你不觉得怎么样,给你一定灵活度之后反而觉得别人的设计有问题,既然你这么用,还搞个Model出来干嘛
|
|
返回顶楼 | |
发表时间:2008-12-23
最后修改:2008-12-23
fight_bird 写道 icewubin 写道 fight_bird 写道 caipanjin 写道 ...
1.使用ResultMap的select会产生“N+1”的问题,这是我不想像ORM那么处理的原因。 ... 实际项目中很少出现N+1的问题,而是x/N+1的问题,其中x可以理解为每页的记录数,无需担心。 实际项目,如果是延迟加载多张表的话,就是M×(x/N)+1问题,怎么能无需担心呢?表的关系稍微一复杂,再加上页面上的显示元素牵涉的表比较多的话,很容易出性能问题。 刚毕业都是作坊式/学究式的设计手段:n多的表关联一起查询,这里有很多最佳实践的细节问题:表结构优化、业务字典......,这是理论和实践差距,这也是经验的价值所在,你做几个大数据量的项目就明白为什么应该设计成x/N+1结果。 完全赞同,理解你说的意思。 我前面也说了不同场景不一样,还说了个“中等复杂查询”,你这里说了个“大数据量”,这个就是前提了,有这个前提当然就是x/N+1,问题是很多项目中的所谓的查询页面没有这个“大数据量”。 首先是评估不同方式抓取数据的性能,然后再是“异常”说的优化缓存(不一定是hibernate缓存)。 对于不同方式抓取数据的评估,主要就是sql性能的评估,是应该考虑大数据量这种业务场景的。 |
|
返回顶楼 | |
发表时间:2008-12-23
rainsilence 写道 orm程度越高,速度越慢
这句话要加个前提,就是大家都使用的同样优化的情况下。 |
|
返回顶楼 | |
发表时间:2008-12-23
不会用的人 总喜欢找一些 要攻击的语言...
|
|
返回顶楼 | |
发表时间:2008-12-23
楼主受苦了.以后还是混混海阔天空吧,这里太危险
|
|
返回顶楼 | |
发表时间:2008-12-23
JE很危险.远离~哈哈
顺便提以下 pojo和vo是不一样的. |
|
返回顶楼 | |
发表时间:2008-12-23
gumpgz 写道 caipanjin 写道 最近做毕业设计的时候,在持久层的框架用了iBATIS,而没有用Hibernate,但是写了几个模块之后越来越不爽。在做像高级查询的这种需要连接多张表的操作的时候,由于iBATIS并不是真正意义上的ORM,所以不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean,真不知道把他们搁置在哪个包里面,新建一个bizModel包与持久层的model包并列?而写死了的model层跟数据库表对应的对象看起来很鸡肋,因为事实上,就查询而言,进行单表操作很少。大家是什么看法?
多表联查,分页查询就不该用ibatis,自己找麻烦。 这种东西都要扬长避短,不能用一个玩意实现你所有的要求。 我很想听听多表联查,分页查询为什么就不能用iBatis了呢? 返回map就不行吗? 多表联查正是iBatis的强项 |
|
返回顶楼 | |