5,386
社区成员
发帖
与我相关
我的任务
分享挑战高手！DELPHI数据控件的有大问题！！！
你好！
比如在对后台数据库的数据进行修改和添加的过程中，用数据控件然后用POST方法，还是用非数据控件的SQL的INSERT和UPDATE方法，请问哪种方法较好？
哪种方法使后台出现的错误最少？
还有缓冲更新方法是不是不可取？是不是使用数据控件的方法不可取？
请高手解释这三种方法的利与弊！
多谢！
比如在对后台数据库的数据进行修改和添加的过程中，用数据控件然后用POST方法，还是用非数据控件的SQL的INSERT和UPDATE方法，请问哪种方法较好？
哪种方法使后台出现的错误最少？
还有缓冲更新方法是不是不可取？是不是使用数据控件的方法不可取？
请高手解释这三种方法的利与弊！
多谢！
...全文
请发表友善的回复…
发表回复
Hank 2001-01-11
- 打赏
- 举报
其实这个问题不应该结束，况且还没有给分！
dragoncircle 2000-09-19
- 打赏
- 举报
我用DELPHI编了一个最简单最笨的程序，用PARADOX表，4个字符字段，4个数值字段外加一个自动编号字段，通过一个TABLE元件，每一记录都用APPEND增加赋值后POST，生成25000条记录用时56~57秒，我的计算机是赛扬300A，内存64M。
CKEN 2000-09-19
- 打赏
- 举报
同意w102272
如此大的数据量根本不适合单机数据库,最好还是用后端数据库服务器.
vfp没用过,不想用,完全是鸡肋,连pb都不如.
不过pb开发数据库程序确实比delphi高了很多(delphi是缺省的控件:P)
delphi的报表功能却比pb高了很多,用户完全自定义的报表pb就很难做,
delphi可以实现,不过也要花点功夫.
如此大的数据量根本不适合单机数据库,最好还是用后端数据库服务器.
vfp没用过,不想用,完全是鸡肋,连pb都不如.
不过pb开发数据库程序确实比delphi高了很多(delphi是缺省的控件:P)
delphi的报表功能却比pb高了很多,用户完全自定义的报表pb就很难做,
delphi可以实现,不过也要花点功夫.
w102272 2000-09-19
- 打赏
- 举报
To Hank:
别试验了，你的测试肯定是这个结果没有错误。
其实这两种应用的环境完全不同，自然没法比。
说老实话，单机环境，我还没有见过比foxpro更快的，
而且最快的不是那个VFP，是dos版本的foxpro 2.0, 如果论sql ，最快的2.5 for dos.
但是在分布式环境下，你试验一下把foxpro作为客户端，采用远程视图或者odbc驱动
再试验试验？那个速度比delphi更加不可恭维。
所以，foxpro的网络环境应用，几乎全是netware,nt下的文件方式访问。
如果一定要比较，
不如比较运行在as400上的db2能够插入多少数据,查询多少数据。未必差劲多少。
但是，大数据系统也不用这个作为性能标准，而是用每秒的事务处理数。
数据库发展到今天，分布式处理是趋势
你选择vfp来做，其实这个应用本身就不是分布式处理的应用，而是密集计算的应用。
当然，你这个应用也不是一个共享软件要求的access或者paradox级别的应用
对于大多数中小企业的应用，这样确实是现实，方便和成功的，因为他们的信息化建设
也就达到了“信息岛”的水平，部署分布式系统反而是累赘了：需要安装独立的服务器，
需要配置网络和网管，需要高水平的DBA, 需要在C/S两端部署和配置，等等。
但是，用户的“信息化基础设施”不会停留在“部门级”或者“厂级”，更多的企业已经
发展到拥有很多的分公司，甚至是跨国公司的规模。客观上，就要求要进行跨地区，
7*24时间的处理和计算，数据和处理在客观上就是分布的，数据一致同步等都成大问题，
也没法采用这样一次性准备好然后处理的方式来完成计算。
只能采用分布处理，（集中存储，或分布存储/定期同步）的模式。
所以，我觉得这个比较其实不是很公正，用单机系统一点之长比分布系统一点之短。
如果我来做这个系统，还是首先向用户建议采用分布式系统，或者采用大型数据库
这样有利于用户未来系统的扩展。
当然，如果项目时间短，钱少，或者人手少，或者用户根本不在乎，也会考虑用VFP，
毕竟VFP在数据库应用上的开发效率比delphi高太多了
别试验了，你的测试肯定是这个结果没有错误。
其实这两种应用的环境完全不同，自然没法比。
说老实话，单机环境，我还没有见过比foxpro更快的，
而且最快的不是那个VFP，是dos版本的foxpro 2.0, 如果论sql ，最快的2.5 for dos.
但是在分布式环境下，你试验一下把foxpro作为客户端，采用远程视图或者odbc驱动
再试验试验？那个速度比delphi更加不可恭维。
所以，foxpro的网络环境应用，几乎全是netware,nt下的文件方式访问。
如果一定要比较，
不如比较运行在as400上的db2能够插入多少数据,查询多少数据。未必差劲多少。
但是，大数据系统也不用这个作为性能标准，而是用每秒的事务处理数。
数据库发展到今天，分布式处理是趋势
你选择vfp来做，其实这个应用本身就不是分布式处理的应用，而是密集计算的应用。
当然，你这个应用也不是一个共享软件要求的access或者paradox级别的应用
对于大多数中小企业的应用，这样确实是现实，方便和成功的，因为他们的信息化建设
也就达到了“信息岛”的水平，部署分布式系统反而是累赘了：需要安装独立的服务器，
需要配置网络和网管，需要高水平的DBA, 需要在C/S两端部署和配置，等等。
但是，用户的“信息化基础设施”不会停留在“部门级”或者“厂级”，更多的企业已经
发展到拥有很多的分公司，甚至是跨国公司的规模。客观上，就要求要进行跨地区，
7*24时间的处理和计算，数据和处理在客观上就是分布的，数据一致同步等都成大问题，
也没法采用这样一次性准备好然后处理的方式来完成计算。
只能采用分布处理，（集中存储，或分布存储/定期同步）的模式。
所以，我觉得这个比较其实不是很公正，用单机系统一点之长比分布系统一点之短。
如果我来做这个系统，还是首先向用户建议采用分布式系统，或者采用大型数据库
这样有利于用户未来系统的扩展。
当然，如果项目时间短，钱少，或者人手少，或者用户根本不在乎，也会考虑用VFP，
毕竟VFP在数据库应用上的开发效率比delphi高太多了
Hank 2000-09-19
- 打赏
- 举报
是的，估计速度差不多，周末我也做了一个测试，分别是VFP和BCB，对比分别如下：
在VFP中，建立一个6个字段的表，有日期、字符、数值三种类型，一条记录占33个字节顺次增加694000条记录，共花去15分钟，然后从694000条记录中SELECT出6940条记录花去17.32秒
在BCB种，怎么也出不来这么多记录，后来用一个现成的测试，通过ODBC从VFP数据库向ACCESS97数据库转数据，21个字段，包括日期、字符、数值三种类型，一条记录占336个字节顺次转移增加750条记录，共花去63秒！
机器：K6-2 500，两条HY -7 64M共128M！
当然，即与DELPHI有关，也与数据库有关（打开VFP数据库明显比ACCESS数据库快）。目前就是这样一种状况，我们是不是发动一下提供DELPHI增加记录的速度？
测试要求：在不同数据库中增加2万、10万、50万条记录所需的时间；从中选择1%记录所需时间；测试机器的CPU及内存。
OK！
在VFP中，建立一个6个字段的表，有日期、字符、数值三种类型，一条记录占33个字节顺次增加694000条记录，共花去15分钟，然后从694000条记录中SELECT出6940条记录花去17.32秒
在BCB种，怎么也出不来这么多记录，后来用一个现成的测试，通过ODBC从VFP数据库向ACCESS97数据库转数据，21个字段，包括日期、字符、数值三种类型，一条记录占336个字节顺次转移增加750条记录，共花去63秒！
机器：K6-2 500，两条HY -7 64M共128M！
当然，即与DELPHI有关，也与数据库有关（打开VFP数据库明显比ACCESS数据库快）。目前就是这样一种状况，我们是不是发动一下提供DELPHI增加记录的速度？
测试要求：在不同数据库中增加2万、10万、50万条记录所需的时间；从中选择1%记录所需时间；测试机器的CPU及内存。
OK！
cybercobra 2000-09-10
- 打赏
- 举报
关注
gzproger 2000-09-09
- 打赏
- 举报
修正一下，不是linux下的sybase，是在一ultra-60(?)机器上跑的；
插入速度大约去到100-800条/秒；飞崽条应用要求如果是插入的话，连我这个
测试床都顶不住。但是如果内部产生速度应该足够，但如果这样好像令人费解，
从数据库内部产生的东西，和工厂的流程岂不是脱钩了？不过即使是插入，换上
牛一点的机器跑sybase，速度还是可以满足飞崽条应用的需要的的。关键这些速
度和用delphi还是什么其他的无关。至于用delphi的本地数据库，可能会比较差。
另外数据库服务器在同等配置的机器上，速度方面可能会比fox差一些，因为fox不需要
象数据库服务器那样做写回滚段等工作。
还有midas我觉得也挺不好用，我们以前用的一个程序，才万把条记录，但是字节数比较多，
结果挺慢的。但那是delphi4.0的了，5.0的好像有新机制了。
那位97年就玩MIDAS的兄台不知道现在还有没有玩？现在的MIDAS和97年的MIDAS有了些进步
了嘛。
另外诸位兄台的高论看的小弟佩服不已，却也胡涂不已：似乎结论是大型数据库应用应该用
vc+sql服务器来做？不过小弟听说华为就是这么做的。也许真的如此吧。
插入速度大约去到100-800条/秒；飞崽条应用要求如果是插入的话，连我这个
测试床都顶不住。但是如果内部产生速度应该足够，但如果这样好像令人费解，
从数据库内部产生的东西，和工厂的流程岂不是脱钩了？不过即使是插入，换上
牛一点的机器跑sybase，速度还是可以满足飞崽条应用的需要的的。关键这些速
度和用delphi还是什么其他的无关。至于用delphi的本地数据库，可能会比较差。
另外数据库服务器在同等配置的机器上，速度方面可能会比fox差一些，因为fox不需要
象数据库服务器那样做写回滚段等工作。
还有midas我觉得也挺不好用，我们以前用的一个程序，才万把条记录，但是字节数比较多，
结果挺慢的。但那是delphi4.0的了，5.0的好像有新机制了。
那位97年就玩MIDAS的兄台不知道现在还有没有玩？现在的MIDAS和97年的MIDAS有了些进步
了嘛。
另外诸位兄台的高论看的小弟佩服不已，却也胡涂不已：似乎结论是大型数据库应用应该用
vc+sql服务器来做？不过小弟听说华为就是这么做的。也许真的如此吧。
gzproger 2000-09-09
- 打赏
- 举报
前面说飞崽条案例的仁兄不知道用delphi开发是用什么数据库？是paradox文件，还是
有类似oracle之类的后端阿。
不过我以前测试过linux下sybase，发现它插入数据的效率令人不敢恭维，用来记录
路由器的log信息会迅速被路由器抛离，而且还是校园级的，不是电信级的。
有类似oracle之类的后端阿。
不过我以前测试过linux下sybase，发现它插入数据的效率令人不敢恭维，用来记录
路由器的log信息会迅速被路由器抛离，而且还是校园级的，不是电信级的。
fyje 2000-09-09
- 打赏
- 举报
你可以使用存储过程尽量减少程序和数据库之间的数据通讯，肯定会很快的。
Hank 2000-09-09
- 打赏
- 举报
不好意思，各位都集中到我的问题上来了，谢谢了，不过我相信这肯定也是大伙要解决的问题
我干脆把VFP的源代码写出来，相信如果你做软件两年以上应该能看懂这些代码（过滤掉了出现错误的提示信息），OK！
&&SELCUTCODE 是全局变量，记录当前剪裁的裁床编号
SELECT SIZES,CUTRATIO FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTRATION
COUNT TO REC &&取出要剪裁的尺码及尺码比例
SELECT SUM(CUTRATIO) FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO ARRAY SUMRATIO &&尺码比例合计
IF SUMRATIO>0
DIMENSION RATIO(SUMRATIO) &&将尺码按顺序及数量转入到一个数组
SELECT CUTRATION
GO TOP
HEAPQTY=0
FOR SIZESQTY=1 TO REC
FOR RATIOQTY=1 TO CUTRATION.CUTRATIO
HEAPQTY=HEAPQTY+1
RATIO(HEAPQTY)=CUTRATION.SIZES
ENDFOR
RATIOQTY=1
SELECT CUTRATION
SKIP
ENDFOR
SELECT TABING
COUNT TO REC &&取飞仔的流水号存入变量MAXTABCODE
IF REC>0
SELECT MAX(TABCODE) FROM TABING INTO ARRAY MAXTABING
MAXTABCODE=MAXTABING
RELEASE MAXTABING &&释放SQL语句取出的数据
ELSE
MAXTABCODE="0"
ENDIF
SELECT CUTCODE,ORDERCODE,SHORTNAME,FABRICQTY FROM CUTELEMENT WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTELEMENTN
COUNT TO REC &&取出要剪裁的布料数据
IF REC>0
MAXBED=THISFORM.PAGEFRAME1.PAGE1.TEXT4.VALUE &&得到床次数据
FOR SIZESQTY=1 TO SUMRATIO &&将存入数组的尺码资料循环存入飞仔表
SELECT CUTELEMENTN &&取布料数据
GO TOP
FOR FABRICQTY=1 TO REC &&将出入SQL结果中的布料数据循环存入飞仔表
MAXTABCODE=CHRTRAN(STR(VAL(MAXTABCODE)+1,8)," ","0")
&&下一行是将所有要求的数据转入飞仔表，每次大约2000条记录
INSERT INTO TABING(CUTCODE,TABCODE,ORDERCODE,CUTBED,SIZES,COLORS,QTY) VALUES(CUTELEMENTN.CUTCODE,MAXTABCODE,CUTELEMENTN.ORDERCODE,MAXBED,RATIO(SIZESQTY),CUTELEMENTN.SHORTNAME,CUTELEMENTN.FABRICQTY)
SELECT CUTELEMENTN
SKIP
ENDFOR
ENDFOR
SELECT TABING
TABLEUPDATE(.T.) &&保存结果
ENDIF
ELSE
ENDIF
然后剩下的一样，将这次产生的记录转入一个表打印出来，然后转入员工工资记录表，差不多了，可以列一下代码
SUMSERIAL=ORDERING.SERIALNUM &&取出工序数量
SELECT * FROM TABING WHERE CUTCODE=SELCUTCODE INTO CURSOR TABINGN
SELECT TABINGN
COUNT TO REC
GO TOP
FOR CUTQTY=1 TO REC
FOR SERIAL=1 TO SUMSERIAL
SELECT SUMWORK
&&下行省略了具体数据，只说明意思
INSERT INTO SUMWORK(...) VALUES(...)
ENDFOR
SERIAL=1
SELECT TABINGN
SKIP
ENDFOR
就是这样一个例子，如果工序数为12，那么这次就会产生24000条记录，不幸的是昨天有人告诉我他以前在UNIX下用C写的一个制衣软件工序会超过99个，死了！
至于DELPHI下的代码，我就不用写了，我试过了VFP、Paradox、SQL-SERVER三种数据库(25000条)，速度都不敢令人恭维！其实就是上面那一点点代码，我想各位再怎么优化也优化不了那里去，这不是由数据库来完成！
我干脆把VFP的源代码写出来，相信如果你做软件两年以上应该能看懂这些代码（过滤掉了出现错误的提示信息），OK！
&&SELCUTCODE 是全局变量，记录当前剪裁的裁床编号
SELECT SIZES,CUTRATIO FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTRATION
COUNT TO REC &&取出要剪裁的尺码及尺码比例
SELECT SUM(CUTRATIO) FROM CUTSIZES WHERE CUTCODE=SELCUTCODE INTO ARRAY SUMRATIO &&尺码比例合计
IF SUMRATIO>0
DIMENSION RATIO(SUMRATIO) &&将尺码按顺序及数量转入到一个数组
SELECT CUTRATION
GO TOP
HEAPQTY=0
FOR SIZESQTY=1 TO REC
FOR RATIOQTY=1 TO CUTRATION.CUTRATIO
HEAPQTY=HEAPQTY+1
RATIO(HEAPQTY)=CUTRATION.SIZES
ENDFOR
RATIOQTY=1
SELECT CUTRATION
SKIP
ENDFOR
SELECT TABING
COUNT TO REC &&取飞仔的流水号存入变量MAXTABCODE
IF REC>0
SELECT MAX(TABCODE) FROM TABING INTO ARRAY MAXTABING
MAXTABCODE=MAXTABING
RELEASE MAXTABING &&释放SQL语句取出的数据
ELSE
MAXTABCODE="0"
ENDIF
SELECT CUTCODE,ORDERCODE,SHORTNAME,FABRICQTY FROM CUTELEMENT WHERE CUTCODE=SELCUTCODE INTO CURSOR CUTELEMENTN
COUNT TO REC &&取出要剪裁的布料数据
IF REC>0
MAXBED=THISFORM.PAGEFRAME1.PAGE1.TEXT4.VALUE &&得到床次数据
FOR SIZESQTY=1 TO SUMRATIO &&将存入数组的尺码资料循环存入飞仔表
SELECT CUTELEMENTN &&取布料数据
GO TOP
FOR FABRICQTY=1 TO REC &&将出入SQL结果中的布料数据循环存入飞仔表
MAXTABCODE=CHRTRAN(STR(VAL(MAXTABCODE)+1,8)," ","0")
&&下一行是将所有要求的数据转入飞仔表，每次大约2000条记录
INSERT INTO TABING(CUTCODE,TABCODE,ORDERCODE,CUTBED,SIZES,COLORS,QTY) VALUES(CUTELEMENTN.CUTCODE,MAXTABCODE,CUTELEMENTN.ORDERCODE,MAXBED,RATIO(SIZESQTY),CUTELEMENTN.SHORTNAME,CUTELEMENTN.FABRICQTY)
SELECT CUTELEMENTN
SKIP
ENDFOR
ENDFOR
SELECT TABING
TABLEUPDATE(.T.) &&保存结果
ENDIF
ELSE
ENDIF
然后剩下的一样，将这次产生的记录转入一个表打印出来，然后转入员工工资记录表，差不多了，可以列一下代码
SUMSERIAL=ORDERING.SERIALNUM &&取出工序数量
SELECT * FROM TABING WHERE CUTCODE=SELCUTCODE INTO CURSOR TABINGN
SELECT TABINGN
COUNT TO REC
GO TOP
FOR CUTQTY=1 TO REC
FOR SERIAL=1 TO SUMSERIAL
SELECT SUMWORK
&&下行省略了具体数据，只说明意思
INSERT INTO SUMWORK(...) VALUES(...)
ENDFOR
SERIAL=1
SELECT TABINGN
SKIP
ENDFOR
就是这样一个例子，如果工序数为12，那么这次就会产生24000条记录，不幸的是昨天有人告诉我他以前在UNIX下用C写的一个制衣软件工序会超过99个，死了！
至于DELPHI下的代码，我就不用写了，我试过了VFP、Paradox、SQL-SERVER三种数据库(25000条)，速度都不敢令人恭维！其实就是上面那一点点代码，我想各位再怎么优化也优化不了那里去，这不是由数据库来完成！
z_p 2000-09-09
- 打赏
- 举报
如果你要产生那么多的数据，是不可能有那么快的速度的。我原来在sybase下用存储器实现也只是10秒中五千条左右。
JGTM2000 2000-09-08
- 打赏
- 举报
数据逻辑给数据库做，业务逻辑在中间层做，最后用一个瘦客户，仅直接访问中间层。这样的结果效率主要取决于数据库。你说的那种数据规模绝对构不成性能威胁。
iforever 2000-09-08
- 打赏
- 举报
语言并不是最重要的,关键是你的设计和服务器的性能,如果delphi这么差,早就被淘汰了
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi
这种说法听起来有道理.
但:
1. 如果一种框架本身就是有限制的, 你还能指望它做什么大东西!
2. 设计的确重要,只可惜真正会大型系统设计的实在太少(一个有100人公司里不会超过5个人).
李维的<Delphi3从入门到精通>
1.李维的书读第一遍\ 佩服
第二遍还是\佩服
照着做\没用.
李维的书里你看不到任何一句说DELPHI有什么不好的话.
但是李维的身份是什么: INPRISE的台湾代言人.
就象徐新华: INPRIES 的中国大陆代言人.
(李维的书(DELPHI方面的)我基本上都有包括台湾版的)
据我了解:(我在做项目中接触过的客户)
有一些财务软件使用DELPHI 的MIDAS技术做的.
这没什么错因为财务软件往往用户少交易量不大系统相对封闭.
用得是地方.
国内MIS就不要讲了大部分都是DELPHI.
(我也是)
不能因为自己用一种东西就说它好的不得了,
这不是一个职业程序员的正确态度.
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi
这种说法听起来有道理.
但:
1. 如果一种框架本身就是有限制的, 你还能指望它做什么大东西!
2. 设计的确重要,只可惜真正会大型系统设计的实在太少(一个有100人公司里不会超过5个人).
李维的<Delphi3从入门到精通>
1.李维的书读第一遍\ 佩服
第二遍还是\佩服
照着做\没用.
李维的书里你看不到任何一句说DELPHI有什么不好的话.
但是李维的身份是什么: INPRISE的台湾代言人.
就象徐新华: INPRIES 的中国大陆代言人.
(李维的书(DELPHI方面的)我基本上都有包括台湾版的)
据我了解:(我在做项目中接触过的客户)
有一些财务软件使用DELPHI 的MIDAS技术做的.
这没什么错因为财务软件往往用户少交易量不大系统相对封闭.
用得是地方.
国内MIS就不要讲了大部分都是DELPHI.
(我也是)
不能因为自己用一种东西就说它好的不得了,
这不是一个职业程序员的正确态度.
CKEN 2000-09-08
- 打赏
- 举报
语言并不是最重要的,关键是你的设计和服务器的性能,如果delphi这么差,早就被淘汰了
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi
存在便是合理,vc代码效率>delphi,如果你的设计不合理vc<<delphi
CKEN 2000-09-08
- 打赏
- 举报
hank,增加纪录的效率非常取决于数据库设计,如果我来增加如此多的纪录,后端选oracle,我会用存储过程来实现,增加纪录的快慢取决于存储过程的快慢,存储过程的快慢又取决于数据库的选择和数据库及表的优化,和语言是无关的.客户端只传送纪录各字段值,这个过程各个语言是没差别的,
如果客户端先对各字段值进行复杂处理,这个过程一定是delphi>pb>vfp
如果客户端先对各字段值进行复杂处理,这个过程一定是delphi>pb>vfp
cyhan 2000-09-08
- 打赏
- 举报
对于大数据量的数据库,Delphi的控件中有多种优化措施,比如打开UpdateCache,可以成倍提高
速度,请参考李维的<Delphi3从入门到精通>,里面有很多地方讲到如何优化数据库访问速度的
问题,我也曾做过一个电信的项目,很简单,把交换机里的数据倒到Sybase里,上千万条记录,包括
计算及合并在内,竟花了六七个小时,后来仔细优化,包括Delphi以及sybase,只花了不到半个小
时.
速度,请参考李维的<Delphi3从入门到精通>,里面有很多地方讲到如何优化数据库访问速度的
问题,我也曾做过一个电信的项目,很简单,把交换机里的数据倒到Sybase里,上千万条记录,包括
计算及合并在内,竟花了六七个小时,后来仔细优化,包括Delphi以及sybase,只花了不到半个小
时.
Hank 2000-09-08
- 打赏
- 举报
同意iforever的观点，当年“九七工程”的数据量也没有这么恐怖！它把数据量分散了，其实每台程控交换机每分钟采集的数据量并不是很大，而且很少出现集中采集的现象，即使出现，也不是很多，每台每分钟5000条已经是很集中了，如果再多那电信发的简直不成样子！
MIDAS，各位看一下李维的那本《Delphi 5.X分布式多层应用系统篇》就明白了！
我是不想退回去搞VFP（但目前只能这样），所以看DELPHI能不能实现我的数据要求！
MIDAS，各位看一下李维的那本《Delphi 5.X分布式多层应用系统篇》就明白了！
我是不想退回去搞VFP（但目前只能这样），所以看DELPHI能不能实现我的数据要求！
Hank 2000-09-08
- 打赏
- 举报
看清楚，我不仅仅是要求查询，最关键的是要求在很短的时间内（1分钟）增加25000条记录！
各位可以试一下，建立一个8个字段的表（数据库随便），建立一个循环，不停的增加，看增加25000条记录要多长时间！至于记录多不是主要问题，查询也可以很简单！例如我说的那个飞仔记录表，我要的查询仅仅是：
SELECT 姓名,SUM(飞仔工资) FROM 飞仔表 GROUP BY 姓名 WHERE 日期＞XX AND 日期＜XXX
其中飞仔表一个月大约120万条记录，员工数大约1500名，各位可以试一下！
如果是年薪要统计，那就算了，从1500万条记录中搜索那么多数据，我感到怀疑！
各位可以试一下，建立一个8个字段的表（数据库随便），建立一个循环，不停的增加，看增加25000条记录要多长时间！至于记录多不是主要问题，查询也可以很简单！例如我说的那个飞仔记录表，我要的查询仅仅是：
SELECT 姓名,SUM(飞仔工资) FROM 飞仔表 GROUP BY 姓名 WHERE 日期＞XX AND 日期＜XXX
其中飞仔表一个月大约120万条记录，员工数大约1500名，各位可以试一下！
如果是年薪要统计，那就算了，从1500万条记录中搜索那么多数据，我感到怀疑！
iforever 2000-09-08
- 打赏
- 举报
我没有贬低DELPHI的意思虽然我也在用VC但我主要还是用DELPHI.
iforever 2000-09-08
- 打赏
- 举报
分布式N-TIER的确是不可避免的趋势.
但是:
数据逻辑给数据库做，业务逻辑在中间层做，最后用一个瘦客户，仅直接访问中间层。这样的结果效率主要取决于数据库。你说的那种数据规模绝对构不成性能威胁。
有人同意DELPHI所谓的三层结构是垃圾吗.
MIDAS这一套东西稳定吗.
我们在97年就用这玩意做了一个两百万的项目,当时这种技术非常时髦.
还可以批上一个IE的外衣.
但到现在还有一个小组在维护这个烂摊子.
DELPHI在数据库访问的确是走在其他开发工具的前面.
但是, 在你使用一项技术前你必须搞清楚它的机制或者说是限制.
撇开ADO不谈(有一个兄弟正在测试)
DELPHI 以前的三阶层无法做大型企业级用\(不稳定)
几十个客户端数据交换量不大交换频率不大还可以应付.
但是:
数据逻辑给数据库做，业务逻辑在中间层做，最后用一个瘦客户，仅直接访问中间层。这样的结果效率主要取决于数据库。你说的那种数据规模绝对构不成性能威胁。
有人同意DELPHI所谓的三层结构是垃圾吗.
MIDAS这一套东西稳定吗.
我们在97年就用这玩意做了一个两百万的项目,当时这种技术非常时髦.
还可以批上一个IE的外衣.
但到现在还有一个小组在维护这个烂摊子.
DELPHI在数据库访问的确是走在其他开发工具的前面.
但是, 在你使用一项技术前你必须搞清楚它的机制或者说是限制.
撇开ADO不谈(有一个兄弟正在测试)
DELPHI 以前的三阶层无法做大型企业级用\(不稳定)
几十个客户端数据交换量不大交换频率不大还可以应付.
加载更多回复（9）
