MIDAS,CORBA,在客户端提出SQL,还是在服务器端写SQL(200分)

  • 主题发起人 主题发起人 ericyeoh
  • 开始时间 开始时间
E

ericyeoh

Unregistered / Unconfirmed
GUEST, unregistred user!
我用CORBA连接程序服务器,但一直困惑于是在客户端的ClientDataset中写SQL提交到服务器
执行好,
还是在程序服务器上写例如这样的SQL:
update table1 set col1=:p1 and col2=:p2
where col3:=p3 and col4:=p4
然后在客户端提交p1-p4和table1这样的参数给程序服务器执行好
第一种方式显然要简便得多,但朋友说第二种方式才充分体现三层结构,可以大家都调用这个
公共的SQL
哪位大哥解答一下吧,谢谢
 
我觉得在服务器端写好,把业务规则写在服务器端,客户端的应用程序可以不用作大的
修改,体现出三层结构,如果把业务规则写在客户端,虽然看起来也是三层结构,但
这更象胖客户的c/s结构,而且维护和扩展都不方便
 
无论在client 还是server端写sql语句,都需要在server上执行。所谓的瘦client端,
并不看重sql是否在client还是server上。这点在windowsDNA中有介绍。
若把sql写在服务端,会使server端臃肿,效率降低,所以建议sql写在client端,传到
server去执行。
 
"update table1 set col1=:p1 and col2=:p2 where col3:=p3 and col4:=p4"
如果你的数据库是一台专用的服务器,象这样的SQL会有好处些,
但如果应用服务器和数据库服务器在同一台机器,
请不要用这样做法,
直接用CLIETNDATASET的EDIT,然后APPLYUPDATE到服务器,
肯定比这样子好,
我试过多次,
而且编程也就最简单的,
只一两句。
 
我倒觉得放在SERVER上交好。这样可以着重于服务端开发。
客户端只要很少代码。适合群体开发。
如果一个SERVER太肥大,可以分为多个APPSERVER。
正所谓分布式嘛。
 
我的建议是采用oop的方式,所以的业务最终划分为企业对象,然后使用方法实现具体功能,
对于你的疑问一种解决办法是,在应用服务器端声明实现方法,然后客户端调用并传递参数。
这样做,能否保证客户端改动最小。
 
可以在数据库端写存储过程,中间层用TAdoDataSetProcedure 取该存储过程,另外再在
中间层定义一个方法,用以根据客户端传来的参数通过存储过程进行数据库更新。这种
方法的效率应该还可以。但是否让数据库服务器的负荷太重了?
 
强烈建议你把Sql写在Server端:
1、若把sql写在服务端,把各种功能的实现都放在服务器端,可以供多个客户端调用,
代码重用!
2、我们知道,一般客户机都在多台机,要升级维护时非常麻烦的,所以我们尽量把客
户端搞的简单一点,把主要的功能事先都放在服务器端,升级时,修改服务器端,
应用程序可以不用作大的修改,体现出三层结构优势。
3、如楼上所说:有利于群体开发。
 
大家讲了很多都对,我再补充两点:
1。如果需要一次读写大量的数据,那把SQL放在SERVER上,这样可以加快速度。
2。如果是零星的查询或写操作,那把SQL放在CLIENT上,这样可以减轻SERVER的负担。
 
我建议不要在Client端用Update,insert,modify等的SQL语句。在Client端调用
ClientDataset的Edit,Insert,Append等,然后ApplyUpdates(0).
因为如果用了Update的SQL语句,则Client必须重新Select才可以看到数据。这样会增加
网络的负担。如果用ClientDataset的ApplyUpdates,则不必重新Select数据。网络的负担
减小很多。
 
OfCourse Server端
 
如果将SQL放在Server端,那为何李维的书上大部分例子都将SQL放在客户端
 
那为什么要死脑筋,跟李维学呢?三层结构的思想理解了,应当会自己发挥一下
 
用得好!在那都行!!
 
在服务器端,则此SQL语句可作为业务规则的一部分,打个比方,若是人事部门、财务部门
都需要此条语句,则可将它作为业务规则、义务逻辑的一部分放在应用程序服务器端;否则
按需要放在服务器端或客户端,例如只有一个部门使用,在客户端没有多少业务规则的情况
下,放在客户端也无妨(记住,瘦客户并非完全没有业务规则)。我个人认为放在服务器端
好还是客户端好,要视具体情况而定,千万别按部就班。
 
我认为应该具体情况具体分析,要抓主要矛盾吗!
 
多人接受答案了。
 
后退
顶部