|
锁定老帖子 主题：这样的应用有必要Hibernate？
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-08-20
三张表，直接用jdbc，写sql啦。
|
| 返回顶楼 | |
|
发表时间：2008-08-20
iBATIS
|
| 返回顶楼 | |
|
发表时间：2008-08-20
JaveEyeBear 写道 我看楼主你的照片也知道你不是什么技术很强的人，你也就是个垃圾，别人想用自然有他们的道理，都没用过不练一下，你自己傻吧！
这评论够强悍，当你用一个手指指着别人的时候，有四个手指指着你自己。 搞不清楚，为何出这样的评论。？？？？ |
| 返回顶楼 | |
|
发表时间：2008-08-21
ibatis
|
| 返回顶楼 | |
|
发表时间：2008-08-21
sole 写道 其实也就有三张简单的表；
数据量特别大，一个表中会产生有几十万，甚至几百万条记录； 更新，删除，插入操作非常频繁，一般都是批量进行的。 公司其他技术人员说，hibernate自动ORM,有自带缓冲,数据库连接池，减少了很多工作。 其实公司没有一人hibernate了解的，只听说而已，现学现用。 我觉得很没必要。用hibernate没有一点优势。 对hibernate了解比较深入的，能谈谈您的意见吗？ 谢谢all 当然可以用Hibernate。 中心思想是“分而治之”，具体些说，是水平拆表。 有好几种被人实践过的Hibernate解决方案。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
Hibernate Shards，
Hiberante+AbstractRoutingDateSource（Spring） Hibernate+C-JDBC 这三种方案 PS：我喜欢拆表...不过要特别注意二级缓存的问题，特别是第二种方案。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
chen-516888 写道 删除，插入操作非常频繁，一般都是批量进行的。
批量的插入和删除不是hibernate擅长的 觉得还是用jdbc好一些 更灵活 Hibernate都是生成sql来操作的，哪有擅长不擅长的区别，大家都是jdbc， 3.0以后也支持批量操作（就是支持生成批量的删除和更新sql语句）， 还有原生sql的支持（意味着你随时可以用原生sql来处理一些棘手问题）。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
配置文件就是代码，不觉的ibatis有多好，还不如Spring JDBC。
|
| 返回顶楼 | |
|
发表时间：2008-08-21
murainwood 写道 Hibernate Shards，
Hiberante+AbstractRoutingDateSource（Spring） Hibernate+C-JDBC 这三种方案 PS：我喜欢拆表...不过要特别注意二级缓存的问题，特别是第二种方案。 楼主又不是问集群解决方案，有必要用这么重的牛刀么？ 二级缓存极难设计出合理的应用，代码代价往往非常高，建议关闭。 hibernate二级缓存这一级的cache策略更偏向于针对业务对象的缓存，自己设计性价比更高。 |
| 返回顶楼 | |
|
发表时间：2008-08-21
在数据量比较大的时候（百万级别以上），资深或正常的DBA ，看到HIBERNTE 打印出来的SQL 语句，会疯掉的，不是因为看不懂。
1 海量数据用表关联，并不是高效的做法 2 我们公司的 SQL 语句（用IBATIS） 每个都要DBA 审核，现在回头看HIBERNATE 的粗俗的SQL语句，只能说，适用于初学者和小型应用，因为风险实在不可控 3 高效的SQL 查询需要建索引，HIBERNATE 3.0里的，无论是HSQL 还是criteria 都不适合DBA 阅读建索引 4 不觉得对大量数据做缓存，是件很划算的事情，因为会消耗很多的系统资源，淘宝现在就有很多缓存服务器，与其这样，像LZ 这样的应用比如用 优化的SQL 语句来降低成本来的划算 |
| 返回顶楼 | |
