发信人: edison()
整理人: edison(1999-10-21 01:46:38), 站内信件
|
哈哈, 两位高人在不断的神侃游标问题, 令我大开眼界呀!
来回看了你们几篇发言, 我产生了几点疑问!
首先我赞成 ilike 所说
"每条fetch语句需要向服务器发送一条命令，也就是需要一个网络对话" 这是肯定的。
但我想知道 ilike 你所说的 "底层的TCP/IP连接" 是怎么回事？
意思是每次一个 fetch 就要建立一次连接？应该不是吧！我们 PB 做出来的程序
客户端与服务器端应该是数据流传输方式，建立连结在开始时的 connect using sqlca;
时就建立好了，以后基于 sqlca 的操作都应该是在流数据，而不用再重新建立连结。
am i right? 大家可以看看 settrans 与 settransobject 两个函数的 help 。
所以每次的 fetch 应该不存在建立连结的问题，但是使用 fetch 命令肯定比select
传输的数据多，至少包括 "fetch" 这个单词！至于其他不同 DBMS 可能不一定了！
我觉得这个问题上双方都有利有弊，直接使用 select 可以减少网络的传输量，但是
加大了网络的瞬间负荷。使用 fetch 增加了传输量，但是他减少了网络的瞬间负荷。
第二，ilike 可否具体讲一下 server 维护一个光标需要多少的资源？可能这是关键
所在！
第三，我对 pthinker 的观点
"瘦客户机和尽量利用服务器资源本来就是目前MIS开发的目标" 不太赞成。
我们现在应该开发基于分布式计算模型、三层结构的软件，才是我们的目标，
将计算负荷分摊开来才是我们的目标。如果总是强调所有工作有服务器完成
那最后不就回到了计算机刚刚开始的时候，网络终端只是一个键盘和显示器！
我觉的网络诞生的意义就在于此, 通过网络联合所有的资源， CPU 资源也不例外！
【 在 pthinker (Thinker) 的大作中提到: 】
: (1) 那只说明PB和FOXPRO一样，不管怎样，先把所有的数据一次（或几次）取回
: 到
: 客户端，这样虽然通讯次数是少了，但网络通讯量却是上千倍的
: 提高的。10台计算机同时retrieve，也会慢得要死！
:
: （2）在客户锻使用游标的话几乎不会存在结果集是20000万条记录的情况。
: 因为不现实,没有含义，如果是 结果集是20000万条记录或更多，因该是做成
: 存储过程调用了！
:
: （3）瘦客户机和尽量利用服务器资源本来就是目前MIS开发的目标！
:
: (4) 如果是查询表结果，交互式修改数据，用DW无可非议，如果是批处理数据
: 小数据量用游标最好，大数据量的话 做成存储过程，在存储过程中使用
: 游标（只能使用游标)
--
谢谢没有在 "将本文章寄一份给原作者" 处打勾, 再次感谢!
※ 来源:．网易 BBS bbs.netease.com．[FROM: bbs.szptt.net.cn]
|
|