Tquery的真相？？？！！！（欢迎大侠们讨论）(300分)

  • 主题发起人 主题发起人 myname
  • 开始时间 开始时间
也许是我思路有问题吧。但是我不管。：）
其实温兄也误会了。我并不是想和你争“多少分钟打开”这个问题的。呵呵
而是和你讨论一个TABLE工作原理。
也许我理解不对吧：
TABLE要工作，首先必须OPEN，对吧？
在SQL监视器里看到，OPEN操作就是“SELECT * FROM XXX”。
也就是说，TABLE要进行工作，必须把相当一部份的数据下载到本地来。才能进行
各种动作。这个对于一个网络系统来讲，是大的负担。而且也是违反C/S，三层的
基本原理：客户机竟量少干活，服务器承担大量运算。否则的话，服务器如果只是
起到“存储数据”的作用。那还不如用文件型的DB算了。
这个是我的反对意见。你看如何？
 
嗯，说到正题了，“SELECT * FROM XXX”并不意味着负担大，
因为查询引擎都是有缓冲机制的，一开始只是很少返回几条数据。
而后续的查询，修改等等，就要看控件与引擎只见如何互动了。
这正是我说ttable的特征，ttable似乎在delphi5中已经有了很大改善，
能充分利用server段提供的各种功能，达到最优化的处理。
相反，tquery则似乎仍然是简单的取数据，就象提问题者所说的，
可能导致一次性读取全部数据，而ttable则未必，因此反而可能对三层有好处。
最近火气比较大，见谅 :-))
 
不客气。能得到温兄指点我高兴还来不及呢。：）
不过温兄只答了第一个问题。
“而且也是违反C/S，三层的基本原理：客户机竟量少干活，服务器承担大量运算。”
这个你怎么看待？ TTABLE虽然方便的实现了增、删、改。但对于查，小弟是实在
不敢恭维的。举一个事例：
一个3000条记录的DB，如果使用TTABLE的如：LOCATE、FINDKEY等方法来查，实在
是件搞笑的事情。这个对于TQUERY是高效、快速的查询。在TTABLE里是慢的可以。基本
查一下，需要4到5秒的时间。才能查到第一条。嘿嘿。如果要查出全部。。。。。。
这是因为数据全部要下载到本地，才能进行查询。在这个方面，似乎根本未体现出什么
缓冲的优势。而且也“闲置”了服务器。
另外，增、删、改的话，TTABLE有时会拼错SQL的。：）
我在ORACLE里建一个有BLOB字段的表。TTABLE会不正常的。呵呵，用SQL监视器查看，
发现TTABLE是拼出如下SQL：
SELECT A1，B1，BLOB1 FROM XXX ORDER BY
后面漏了东西。西西。
虽然这个话题不是什么大不了的事。不过，对问题要研究到底，这个是温兄教的噢。^_^
 
最近的讨论很精彩，我喜欢。
 
wo faint!!简直受不了你 :-))
还是简短点吧：
〉〉“而且也是违反C/S，三层的基本原理：客户机竟量少干活，服务器承担大量运算。”
不同意，第一，这只是C/S的原理，与三层无关，三层更主要的是逻辑的分离，他不可能脱离C/S而进行平衡负载。
其次，就算是C/S，我前面已经说了，TTable似乎能够更好的利用server提供的功能。
这话什么意思呢？当然是工作仍然由server完成，只是ttable能够更好的支持。
你再看看myname的第二个帖子，10万条记录啊！不比你的三千条更有说服力？
如果你还是不同意，我已经无话可说了。
>>这是因为数据全部要下载到本地，才能进行查询。
>>在这个方面，似乎根本未体现出什么缓冲的优势。而且也“闲置”了服务器。
有点荒唐，缓冲还是下在到本地，是drvier的事情，table说了能算么？
>>另外，增、删、改的话，TTABLE有时会拼错SQL的。：）
我简直彻底晕倒，这个问题你得赶快报告borland，和我说干什么？ :-)
不过我到真是怀疑呀？虽然delphi bug不少，不过要是“ttable 不能打开oracle 带blob表”
这个问题都没发现，borland的测试人员简直是白痴。
（这不是说反话，如果这个问题真的存在，borland的测试人员就是白痴。）
其实你的核心观点不过是ttable只能把数据下载到本地才能操作，可惜这是绝对错误的。
即使是我们说的"ttable改进"之前，这也不是事实。
你如果不相信我说的，随便找论坛上的人问问，他们用ttable打开离线包，增/删/改，用多长时间？
我和其他人的一再实验，都已经证明了这一点，而你的实验，抱歉我实在无法置评。
顺便跟大家说一句，今天开始会很忙，有什么问题，以后慢慢慢聊。 :-))
 
个人观点：
1、对于单表操作，TTable是胜任的，这毋庸置疑；
2、对于复杂查询（多表，或复杂条件），显然TQuery来的方便；、和高效；
3、显然，用TTable对View操作是个好注意；
4、同意一刀同志的观点，TTable大量优化了C/S的性能，提供了不可思议的服务器端优化，是效率高的难以想像，//同志们可以自己体验一下
5、始终认为：使用select *的确有违高效C/S精神，不过既然效率那么高……去它的精神先
 
忍无可忍！
>> 一个3000条记录的DB，如果使用TTABLE的如：LOCATE、FINDKEY等方法来查，实在
>>是件搞笑的事情。这个对于TQUERY是高效、快速的查询。在TTABLE里是慢的可以。基本
>>查一下，需要4到5秒的时间。才能查到第一条。嘿嘿。如果要查出全部。。。。。。
我的K6 266也比这快不少！真不知你用的是什么牛机。
 
大侠们在此过招，本是没资格的，但这么热闹不凑一下，好象又对不起这个早起的早上。
以下仅为个人意见，方家别笑.
1.table并非一无是处，曾经在很长的一段时间内我不用，但近来发现又回去了，起码一点
insert/update/delete操作时很简单很方便.
2.table.insert与query.insert(如能)是在服务端是等效的，我在ms sql server 6.5下跟踪了都是生成
insert table(...) values(...),同样的道理update
3.但dephi翻译此语句table与query的机制是不是一样就不知了，二者此时的速度取决于此
4.table的坏名声来源主要在于:table.open="select * from table"
5.用table去查询是万万不成的.
6.关于Tupdatesql我最近正准备去深入的看看，我怀疑他是有点问题
再说了，看nba去
 
太多了，看得我头都大了，鸡蛋你这个该死的，这木复杂的问题，想考我呀，
实话给你说吧，本人最大的数据库不超过1000条纪录，用的PIII500+128M,
所以从来不考虑速度。：）
在不需要复杂查询的条件下决不用TQuery,我喜欢TTable(简单好用)……
好了，够了吗？；~
 
好了好了。我不说了。：（
你们都有大道理。就我机子破。。。。。。
本来只是想和大家讨论一下问题，既然大家都不客气。我也不想多说了。
就此告辞。
 
值得说明一下的是，也许我的理由，并不能使一些人同意。但是
我来这里目的只有一个，就是讨论问题。这个也是大富翁成立的理由。
正确的答案，应该能够以足够的理由，说服错误的答案。不管我的观点是否正确，
至少，我给出了实验、事例、数据和个人理由。大家应该在学校做过辩论吧？
A方要说服B方，并不在与A方人多，或则大谈B方如何“荒唐、可笑、绝对
错误、忍无可忍。。。。。。”，就能取胜的。而是要给出充足的理由。
如果大家能象sonie那样的话，我想也许会更好些。只是有些朋友连题目也没看
清，就大谈“忍无可忍”。（人家在说网络上的，他在讲本地上的）。
如果是这样的话，我认为我个人应该退出本话题，免得伤了大家的和气。各位爱
怎么样，悉听尊便。
 
给出我刚刚获得的数据，有些地方的确有些疑惑……
mssql 2k, bde, k6/300 128m ram, richbbs dts to mssql query for dbo.letters set ID to PK
Now for TTable
Open a table : 601
Find the record in the cache with index: 0
Find the recorddo
es not exist with index: 80
Find thedo
es not record in the cache with index: 70
Find the record in the cache without index: 5027
Find the recorddo
es not exist without index: 60
Find the recorddo
es not in cache without index: 70
Filter the table with INDEX: 0
UnFilter the table: 0
Filter the table with INDEX: 100
UnFilter the table: 100
Update a record: 26418
Delete a record: 231
Now for TQuery
Many records without index 892
1 record without index 6058
Many records with index 531
1 records with index 330
 
>1 record without index 6058
使用了top 1
 
to 老吴：
没有这么严重吧？不过有一位同志说了一句，看样子也是不了解情况而已，
你也不能一棍子打死啊？再说了，你这一棍子也太狠了，把自己都给打死了，以后还咋办哪？ ^_^
to CJ:
太乱，你是不是整理一下？想说什么呀？
 
我也刚做了一个试验：
一个project,上面放一个tdatabase控件，驱动选择MSACCESS，数据库
使用历险数据库。放一个TTable,一个TQuery,两个TDatasource，分别
指向ttable和tquery,再放两个dbgrid,datasource分别是那两个datasource.
全部打开。
环境：pII300+196M+win2000adv.server
结果如下:
<table border="1" cellspacing="1">
<tr>
<td bgcolor="#0000FF"><font color="#FFFFFF">操作</font></td>
<td bgcolor="#0000FF"><font color="#FFFFFF">TTable</font></td>
<td bgcolor="#0000FF"><font color="#FFFFFF">TQuery</font></td>
</tr>
<tr>
<td>open</td>
<td>瞬间</td>
<td>瞬间</td>
</tr>
<tr>
<td rowspan="2">查找<br>
id=200403</td>
<td>locate：2-3分钟</td>
<td rowspan="2">sql:瞬间</td>
</tr>
<tr>
<td>filter：2-3分钟</td>
</tr>
<tr>
<td>添加</td>
<td>Append:瞬间</td>
<td>sql:瞬间</td>
</tr>
<tr>
<td>last</td>
<td>瞬间</td>
<td>第一次：5-6秒<br>
以后：瞬间</td>
</tr>
<tr>
<td>recordcount</td>
<td>瞬间</td>
<td>第一次：5-6秒<br>
以后：3-4秒</td>
</tr>
<tr>
<td>moveby(5000)</td>
<td>2-3秒</td>
<td>2-3秒</td>
</tr>
</table>
顺便问一下，怎样使用TTable进行memo字段的like操作？
 
测试环境mssql 2k, bde, k6/300 128m ram
数据库richbbs 用dts 到 mssql 200
使用表：dbo.letters ID 建立了 PK
TTable表现：
打开(Open) : 601
查找在cache内记录（locate很前面的）: 0
在有索引的字段上找不存在记录: 80 //locate
查找不在cache中但有索引字段的记录: 70 //locate
查找cache中无索引: 5027 //locate
查找不存在且无索引的: 60 //locate 这两个比较怪！我命名断开所有连接了（keppconnect := false。close）
查找无索引且不在cache中: 70 //locate 可还那么快，也许是bde服务器端的优化……
过滤索引字段: 0 //KAO!
还原: 0
过滤无索引: 100 //好快，估计是部分数据过滤（目前显示在DBGrid中的）
还原: 0
修改更新 26418 //Edit;
FieldByName('fromuser') := 'a';
post;
删除记录: 231 //Table1.Delete;
TQuery表现：
SELECT许多记录出来有where 892
select top 1 无where 6058
SELECT许多记录出来有where中包含index了的字段 531
select top 1 where中包含有index了的字段 330
 
to cj:
1.缺少ttable insert的数据（好人做到底，谢了）
2.你的数据单位是什么？如果我没糊涂，应该是毫秒？
3.怎么有“查找无索引且不在cache中”竟然比“查找cache中无索引”快几十倍？
这从逻辑上说不通，是不是因为测试状态的原因？
 
1.of coz!!!直接Gettickcount - t出来的，我加了个自动log过程，所以这里还要取出log的时间
3.我用类似代码测试的，公平期间，采用第二遍执行的结果
with Table1do
begin
open;
locate...
close;
database1.close;//keepconnection 为 false
open;
locate...
close;
database1.close;
end;
这样的结果，可能是bde驱动的优化吧……
 
to 吴剑明：
我刚刚看cakk的帖子，又把你的帖子看了一遍，里面好像还有指出我的言语不当之处嘛！
我刚开始还以为就说lha呢，嘿嘿，我也够粗心的。
不过，前面好像还看见小猪说：“最近的讨论很精彩，我喜欢。”
说明大家并没有当真，希望你也这样吧！
（趁鸡蛋还没明白过味儿来，快步走过了街的拐角处...）
to all: 用ttable+locate作查询，除非有什么特殊的需要，否则纯属自寻烦恼，这一点所有的人似乎都没有不同意见吧？
不过，做法归做法，技术归技术，还是不能不说的：
Locate之所以慢，并非由于要把数据全下载到本地，它可以通过server端的cursor来实现，
事实上也肯定如此。但是即使这样，比起进行过各种优化的查询引擎来讲，实在慢的太多了。
反之，如果有索引，速度就会快很多，大概是如此吧。
因此，速度慢的根本原因在于它没有任何优化的逐条比较的搜索的模式，而不在于本地还是server端。
如果由它locate慢而得出其他并不属于ttable缺点的结论，当然是不合理的。
另外，什么是全部下载到本地呢？大家都知道，ADO里面设定client cursor就是全部下载到本地。
这样的话，我用ttable花1秒钟就能打开的数据库，用adotable花1分钟多，差别如此之大，
是绝不可能被忽略的，这就是我那个“绝对XX”的来历。因此，如果ttable要把数据下载到本地才能动作，
那么它完成一个操作的时间应该是"下载时间+动作时间"，而且下载时间是绝对占大头。
但是，所有人的试验都没有能够证明这一段时间的存在，因此...
这样解释应该合理了吧！
 
恩，我都看到了。感谢温兄好意。
如果我言语有过激处，请原谅。
 
您必须登录或注册才可回复。

Similar threads

不
Intel CPU的CPUID指令(转载) - 不得闲
回复
0
查看
608
不得闲
不
不
XE6 FMX之控件绘制与显示 - 不得闲
回复
0
查看
555
不得闲
不
X
初识kbmmw 的多语言支持 - xalion
回复
0
查看
703
xalion
X
S
[教程]程序保存数据的防断电处理策略
回复
0
查看
911
swish
S
不
奇淫怪巧之在Delphi中调用不申明函数 - 不得闲
回复
0
查看
876
不得闲
不
后退
顶部