浏览 9526 次
|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2003-10-29
:arrow: 孰优孰劣：使用hibernate管理持久层，还是直接使用Oracle（之类的商用数据库）扩展实现的面向对象功能？
请不要告诉我后者移植性不好。（这点我和领导说过，但他表示，我们的客户只可能使用三种数据库系统：Oracle，DB2, SQL Server/Sybase，所以，可以不需要什么很好的移植性。在这点上，我没能说服他） 请就二者的性能和易用性发表意见。 个人感受：很不喜欢写存储过程，而且总是尽量在做系统时不去写这类东西，所以，自然而然也就不喜欢使用某个数据库专有的东西（如扩展的面向对象功能）来做应用系统。而且，看了一下Oracle提供的面向对象sql语句，感觉用起来上手很慢，复杂程度也很高，估计Oracle推广起来也会很困难。 但自己并没有真正对标题中的二者进行过测试和比较。——所以，才想来向各位求教。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2003-10-29
这两者没有什么冲突的地方，除非你采用Oracle的SQLJ加上Oracle自身复杂的数据库对象，否则和Hibernate并无任何重叠的地方。而SQL Server还没有这么强的功能。
|
| 返回顶楼 | |
|
发表时间：2003-10-29
几个问题需要考虑,
一是数据库服务器的负载承受能力, 如果把持久层放到数据库里, 数据库不仅要查询更新数据, 还要保存持久层PO. 内存和cpu开销很大. 二是应用分发的问题, 如果系统扩大为多数据库环境, 数据库内的应用的分发和交互是一个很大的问题. 三是数据库联结的问题, 没有中间层, 每个客户都需要一个连接来保持session 对象, 不可以用oracle的MTS或app server 的connection pooling. 多数据库连接对数据库开销影响很大. 还有就是oracle对象sql语言的成熟性问题. 看看oracle 自己的application development framework吧, 是基于j2ee的. http://otn.oracle.com/products/jdev/htdocs/905/adffaq_otn.html |
| 返回顶楼 | |
|
发表时间：2003-10-30
yyanghhong 写道 几个问题需要考虑,
一是数据库服务器的负载承受能力, 如果把持久层放到数据库里, 数据库不仅要查询更新数据, 还要保存持久层PO. 内存和cpu开销很大. 能不能解释的更详细一些？ yyanghhong 写道 三是数据库联结的问题, 没有中间层, 每个客户都需要一个连接来保持session 对象, 不可以用oracle的MTS或app server 的connection pooling. 多数据库连接对数据库开销影响很大.
我们并不是不用APP SERVER，而只是将持久对象的存储管理交给数据库，在应用系统中，对持久对象的操作仍然按以前实施普通关系型数据库应用一样，用data source，用connection，用statement，为什么说不可以用connection pooling呢？ yyanghhong 写道 还有就是oracle对象sql语言的成熟性问题.
这的确是一个反驳点。 |
| 返回顶楼 | |
|
发表时间：2003-10-30
首先说明我是一个数据库的忠实用户者。
到底数据库在你们的项目中的地位是什么？如果就是单纯的一个数据仓库，不需要任何数据库（oracle、sql server 、sybase）特性，就可以完全忽略数据的存在，管他用的是什么东东，就用hibernate。这样的结果会很糟，时间久了system会越来越慢，最终谁都受不了。 反之，用了hibernate用作普通的业务处理，能够利用oracle、sybase特性的地方，比如巨型数据的查询等，最大程度上用数据库支持。 我认为用hibernate实现还是用DB实现都是可以的。个人推荐混用。 |
| 返回顶楼 | |
|
发表时间：2003-10-31
引用 是数据库服务器的负载承受能力.
database不可以hold太多数据对象, 应该只把长时间大开销的任务放到数据库stored procedure里, 而且用对列来管理. 小的操作就不用了, 得到数据后就数据库就释放cursor. 引用 我们并不是不用APP SERVER，而只是将持久对象的存储管理交给数据库，在应用系统中，对持久对象的操作仍然按以前实施普通关系型数据库应用一样，用data source，用connection，用statement，为什么说不可以用connection pooling呢？.
我不太明白你指的这个数据库持久对象是什么, hibernate用session来管理和隔离PO, BO和PO在一个session里, 你如果把持久对象放到数据库里了, 对于BO来说, 如果用pool, 每次访问的数据库连接不同, 他怎样去找他的PO, 难道还需要每次都look up吗. |
| 返回顶楼 | |
|
发表时间：2003-11-04
yyanghhong 写道 我们并不是不用APP SERVER，而只是将持久对象的存储管理交给数据库，在应用系统中，对持久对象的操作仍然按以前实施普通关系型数据库应用一样，用data source，用connection，用statement，为什么说不可以用connection pooling呢？
我不太明白你指的这个数据库持久对象是什么, hibernate用session来管理和隔离PO, BO和PO在一个session里, 你如果把持久对象放到数据库里了, 对于BO来说, 如果用pool, 每次访问的数据库连接不同, 他怎样去找他的PO, 难道还需要每次都look up吗. 我举个例子吧。 例如：有三个类——student，class，cource。其中student和class是多对1的关系，student和course是多对多的关系。在oracle数据库里按照oracle提供的面向对象的sql，建立三个object，同时建立三个object table。——这就是我所说的“将对PO的管理交给数据库”的意思。 同时，在写web应用时，采用JDBC方式，根据JNDI名得到一个datasource，接着获得connection和statement，然后用statement写sql语句。——这就是我所说的“在应用系统中，对持久对象的操作仍然按以前实施普通关系型数据库应用一样”。 不需要每次都lookup啊。 而采用hibernate的话，就不使用oracle提供的那些面向对象的sql，而是将student、class、course三个类映射成oracle里的表，在利用hitbernate管理持久层，对于业务逻辑的开发人员而言，他们就不需要写什么oracle的sql了，只要直接对以POJO形式出现的PO进行操作就ok了。 所以，我对于你说的： yyanghhong 写道 三是数据库联结的问题, 没有中间层, 每个客户都需要一个连接来保持session 对象, 不可以用oracle的MTS或app server 的connection pooling. 多数据库连接对数据库开销影响很大. |
| 返回顶楼 | |
|
发表时间：2003-11-04
grey_like 写道 首先说明我是一个数据库的忠实用户者。
到底数据库在你们的项目中的地位是什么？如果就是单纯的一个数据仓库，不需要任何数据库（oracle、sql server 、sybase）特性，就可以完全忽略数据的存在，管他用的是什么东东，就用hibernate。这样的结果会很糟，时间久了system会越来越慢，最终谁都受不了。 反之，用了hibernate用作普通的业务处理，能够利用oracle、sybase特性的地方，比如巨型数据的查询等，最大程度上用数据库支持。 我认为用hibernate实现还是用DB实现都是可以的。个人推荐混用。 我们的应用就是普通的MIS系统，查询和统计很多。 why？——“时间久了system会越来越慢？” |
| 返回顶楼 | |
|
发表时间：2003-11-12
yyanghhong已经说的很明白了
|
| 返回顶楼 | |
