关于O/R Map的讨论(200分)

  • 主题发起人 主题发起人 lsj
  • 开始时间 开始时间
L

lsj

Unregistered / Unconfirmed
GUEST, unregistred user!
在数据库操作中最常见的就是发送一个SQL检索出所需的数据,一般传送到客户端的是原始数
据,而不是对象,所以在没有面向对象数据库支持下,我们必须自己建立一层O/R Map,将关系
数据库中的取得的大量数据转换成对象,暂且不论这个O/R Map如何建立,很可能一次就要创
建数千个(甚至更多)对象,客户端连上来的数量一多,每个都查询不同性质的数据,这样就无
法使用缓冲了,这样反复的创建对象,会对服务器造成很大的负担.而存储过程和预定义SQL
我以前用delphi的时侯做过,取来数据后,客户端还得对数据再加工抽出有用的信息,也就是
客户端得了解数据结构,不可避免地将界面和逻辑混在一起了.
总而言之,就是数据->对象的转换这一环节应找到一个合适的解决办法,否则一一映射转换带
来性能问题(我估计是性能上的问题主要是由创建对象过程及垃圾回收机制引起,对象本身所
引起的内存消耗与原始数据相比应该差不多),不转换就破坏了封装的完整性,也失去了OO的
最大优点.
请大家指正~~
 

TDataSet本身不是一个对象，
没有必要把一条记录，或一条记录中每个数据当作一个对象
 
TDataSet之类的东西只是一个数据集,以我的理解,一条记录就对应一个对象,一张表就对应一个类,而
一个数据集对应着一个表或视图
 
以前讨论过一点：
http://www.delphibbs.com/delphibbs/dispq.asp?lid=882692
 
曹大侠,看过你的帖子了,你的那个帖子主要是围绕如何实现O/R Map的讨论的,我现在困惑的
是有没有必要做这个映射,因为我得考虑一下性能问题,你在实践中是怎么处理这个问题的?有
碰到性能问题吗?
 
这是另一位网友的意见：
也许，你需要建一个由DAO(Data Access Object) 和 VO(ValueObject) 构成的数据层.
这样对于视图逻辑，数据是经过封装的，不需要知道底层数据的存储结构，只通过 VO
和 DAO 的接口，就可以进行 CRUD(Create, Read, Update, Delete) 操作．
 
一一映射转换带
来性能问题(我估计是性能上的问题主要是由创建对象过程及垃圾回收机制引起,对象本身所
引起的内存消耗与原始数据相比应该差不多),不转换就破坏了封装的完整性,也失去了OO的
最大优点.
点击展开...
我的意见当然是一定要实现OR映射。不然写程序太痛苦。生不如死啊。
 
好,那我就确定下来做这个O/R Map,性能问题到最后再调整
迟点我把我的方案贴上来,还请曹大侠和各位高手指正
 
在中间加一个应用层作转换，跟三层结构一样
 
现在我对这个问题的认识还比较模糊,我的理解基本上是这样:
问题的产生是由于关系数据库对数据的存储方式与Java对象之间不匹配
解决办法:
1.将ResultSet转换成Java对象表示
优点:客户端编程是对象与对象之间的交互,降低了复杂性,隔开了客户端与数据库
缺点:ResultSet的数据量一大可能会引起性能的迅速下降(现在我还没有对此做测试,仅仅是推测)
2.将ResultSet转换成XML
优点:通用,可用XSLT转成HTML
缺点:缺乏数据操纵能力,XML的解析带来了额外的负担
现在我的应用是以查询为主,所以我打算用第2种方案
请各位多指点~~~
 
第一种方案在数据量大时的性能下降在一定程度上可以忽略的，当然这取决于你的
硬件环境，但在我这里的使用表明，性能上的下降不是很大，其实java构造一个对
象虽然慢，但如果合理的使用对象池的话，性能上还是可以保证的。
第二种方案xml的解析有可能带来令人头痛的性能问题，曹晓钢好像已经碰到了吧，
出来说两句怎么样。对于这一点，你要有充分的心理准备。
补充一下，我这里构造一个映射一千条记录的对象，时间只有几十毫秒，还包括sql
查询的时间，而且是在我开发用的破机器上，当然这是在单用户情况下，在考虑并发
的生产环境，我发现其实最大的问题在数据库并发查询上，我们作压力测试时基本上都是
数据连接池首先不足，导致系统性能下降，在连接池足够大的情况下，似乎并没有
碰到构造对象的性能瓶颈。
情况下，
 
看看这篇微软的文章：
==========================================================================
http://www.microsoft.com/china/msdn/library/dnbda/html/BOAGag.asp
设计数据层组件并在层间传递数据
==========================================================================
将关系数据映射到业务实体
实现数据访问逻辑组件
实现业务实体
事务处理
验证
异常管理
授权与安全性
部署
==========================================================================
上面提到的问题都有讨论。
 
to avant:
你推荐的文章我看了,写得很好,谢谢!
to 小猪:
现在我还不会做压力测试 :-(
现在我这里的服务器是电脑城组装的双P-III 1G,512M内存(8000多块的机器)
 
小猪,你说的很有道理啊,我帮你帖上来了 ^_^
这是原文:
基于数据库的性能分析，其实不一定要做多大的数据量，写几个性能比较差的视图，多用点
union和外连接之类的，一点点数据也可以做到比较好的效果，因为你不需要对数据库本身的
性能作测试，只是关心在作并发的复杂查询时程序本身的性能如何。我个人感觉一个耗时大约
两三秒的查询应该是比较典型的应用查询，基于这样的速度作并发时其实就会发现瓶颈通常在
于数据库的连接上而不是在作o r maping。
我这里有一个比较典型的例子，我们是作了o r maping的，出于防止超时的考虑，我们在
op层作了限制每次查询只返回不超过1000条记录，系统中有一个查询正常情况大约是返回
4000－6000条记录，但并不是简单的单表，因此查询速度是非常慢的，差不多一次查询耗时3－4秒
（在一台很破的机器上，这样便于作性能优化），我们只能是重复查询6次（或者更多，或者更少），
得到6个maping的对象，然后遍历这六个对象，构造一个新的maping对象，实际上测试的结果表明，
不管作了多少次的遍历（当然不能太多^_^）,耗费的时间基本上就是一次查询时间的整数倍，基本
上没有看到因为o r maping造成的性能损失。
这里需要强调一点的是,就是那个查询，在我调试的机器上是20秒左右才能出结果，但在我们
真实的运行环境下大约是1－2秒，这跟实际环境的硬件性能是分不开的，主要是内存，基于java的
应用，内存不足带来的性能上的问题比代码带来的问题要大的多。
实际来看一下，作o r map只是需要遍历结果集一次然后生成对象，而基于xml则需要对xml文本
作多次解析，这里带来的性能上的损失是很大的，前者只需要简单的加大内存就可以在一定程度上
提升性能，而后者需要的多次解析在必然对cpu提出更高的要求。一般来说，加内存总比加cpu方便
得多，是不是？
我提到曹晓钢已经碰到了性能的问题，也是前几天跟他聊天的时候知道的，不过他的情况比较
特殊，一个1G内存的机器上又要跑db2，又要跑他们自己的应用，基于xml的解析方式便给他们带来
了麻烦，不过他们好像已经找到了一些解决办法，具体你可以向他请教一下。
我没有作过基于xml的应用，因此对使用xml来作数据映射在性能上究竟如何没有具体的概念，
我只是想说一点的就是基于o r maping只要设计合理，是不会有太大的性能上的问题的。
 
no ,no.我的情况中xml是作为一种通用的树型结构的。实践证明XSLT性能实在是不高。除了使用client
side XSLT（就是现在delphibbs使用的这种方法）以外，只能够利用xalan自己的方式把一个XSLT翻译成
java class,（好像叫translet），然后用它来直接处理XSLT,效率应该会快很多。我说应该，是因为实际上
我没有做这一部优化，我觉得我们现在的性能已经不错了。如果随着使用人数增加，我是会考虑这样使用的。
XSLT还有一个问题就是消耗内存非常多。O/R mapping是基于比较简单的JDBC的，内存消耗很小，而XSLT却是
一个很复杂的过程，解析，处理的复杂度远远超过简单直接的JDBC O/R mapping. 所以使用server side XML会
给服务器带来很大的影响。
总之来说，如果你的应用本身依赖于XML,比如你的系统的输出就是一个XML，(web service?)或者基于xml的报表，
或者你对XML已经非常精通，完全可以控制它的性能，否则会带来很大的痛苦。
从这个角度上来说，yysun使用client side XSLT，真的是非常好，利用了XML减少了网络流量，降低了服务器负载，
还标准化了各个叶面的结构，是非常成功的。而且client端XSLT做的也很成功，效率不算低。
 
关于O/R Map这个问题真是越想越有意思.我原来对这个问题的认识仅仅是数据库的每一列
数据对应着某个类的一个属性,这样我只是将结果集中的数据简单的做一一映射.这样我的
代码很简单--多表关系我是用视图处理,基本是单表映射.撇开是否使用视图不论,我的
做法是自己写SQL,实际上我做的是Resultset(Rowset)->对象的映射,而且还只是用于查询.
所以我没有考虑到并发的问题.也就是说CRUD四个基本操作我并没有封装在一个对象中.
当我试图完整封装这四个基本操作时,我发现自己的代码迅速的膨胀起来,而且出错了.
现在我只是在做单个表->单个类的映射,但假如我们是要构建一个复杂的系统,有许多对象,
而且具有继承结构时,我担心代码的复杂度会大大增加,如果仅仅是一个对象的转换就要写
很多的代码,那构建复杂一点的系统时,这个O/R转换层将带来很大的工作量.
各位是如何做O/R Map的呢?
 
首先，单一resultset <->单一类集合还是比较容易的。 复杂系统无论在怎么复杂，两个具有联系
的表之间无非是1;1, 1:N,N:N的关系。只要实现了这三种关系，什么事情都好办了。
A:B=1:1,很简单，你在你的类B里面另外再加一个方法: B.getInstance(A),得到从A到B的映射
或者B.getA(),从B的当前instance得到B;
A:B=1:N, 这是一个master/detail关系。 A 应该具有类似于如下的方法： A.getBCollection();
得到B从属于A的collection;
B则有：B.getAInstance(),从B的实例得到A.
A:B=N:N, 应该A和B都有A.getBCollection()的方法。
根据需要，程序员可以自行决定是否实现进一步的映射。比如你从数据库中得到A的一个实例的时候，如果
A:B=1:1,那么你可能希望直接把B融合到A中去，或者自动执行A中一个internal load B的操作，把B
作为一个内部成员也load到内存中来。但是假如A:B=1:N,那么是否执行自动加载B就要慎重对待。一不小心
就会带来严重的性能问题。假如B:C也是1:N,那么如果二者都是自动加载，内存中会出现指数级的增量风暴，
后果很严重。Castor的JDO据说就存在这样的问题。
 
其实ejb的模型在这方面做的不错，可是性能上的问题我一直没有
解决，据说其实ejb性能并不差，看来是我自己掌握的不好了，也没办法。
我们目前做的东西在某种程度上参照了ejb的模型，不过对于上面曹晓钢提到的
多表之间的映射关系，我们基本上还是由程序员自行实现的，在基本框架模型
中并没有考虑这个东西，因为反正也做不了多好，做了用处也不大，还不如不做。
 
我认为对于多对多的关系是数据库设计的问题,而且,根据数据库原理来说,多对多是尽量要避免得
一般都用1对多代替,或者中间价格连接表,所以对于OR/MAPPING主要应该考虑1对1和1对多的关系,
曹说的1对多这个问题,我也遇到过,就是要多次调用实例,这样性能会下降很快
 
您必须登录或注册才可回复。

Similar threads

S
【教程】QJSON 创建根结点为数组的 JSON 内容
回复
0
查看
520
swish
S
S
[教程]使用 TQJsonInputChannel 来重复获取 JSON 对象
回复
0
查看
692
swish
S
X
在datasnap 中使用unidac 访问数据（客户端） - xalion
回复
0
查看
775
xalion
X
X
使用kbmmw 生成客户端delphi函数原型 - xalion
回复
0
查看
704
xalion
X
不
ISO8583报文协议（转） - 不得闲
回复
0
查看
862
不得闲
不
后退
顶部