Rss & SiteMap

Foxtable(狐表) http://www.foxtable.com

新一代数据库软件,完美融合Access、Foxpro、Excel、vb.net之优势,人人都能掌握的快速软件开发工具!
共4 条记录, 每页显示 10 条, 页签: [1]
[浏览完整版]

标题:[求助]在设计fa piao管理系统时遇到的两个问题

1楼
bjljb 发表于:2010/1/31 16:03:00
为了说明问题,附件中有三个简单的表,这三个表都是外部表,存储在SQL Server 2005数据库中。
【fa piao封面】表大约有12万行,【fa piao明细】表大约有230多万行,【fa piao验旧】表大约有50多万行。

各表之间的关系是:
1、【fa piao封面】表和【fa piao明细】表通过字段“fa piao本号”进行关联,关联名称为“fa piao本”;
2、【fa piao明细】表中的“fa piao号码”列是从【fa piao封面】表中对应的“fa piao起号”开始,逐行加1,一直到“fa piao止号”为止;
3、【fa piao验旧】表中的“fa piao代码”和【fa piao封面】中的“fa piao代码”是两个有交集但不完全相同的集合;
4、【fa piao验旧】表中的“验旧起号”和“验旧止号”与【fa piao明细】表中对应的“fa piao号码”的关系是:每一本的总量相同,但明细是逐份录入,验旧是分段录入。

问题1、如何计算【fa piao封面】表中每一本的“累计填开金额”?
此前已经通过公式列得到这个结果,公式为Sum(Child(fa piao本).填开金额)但公式结果不能保存到后台数据库中。
现在fa piao本数量已经达到10万以上,明细数据有200万之巨,该如何重新计算呢?
是用SQL语句在后台解决好,还是通过Foxtable的代码来解决更好、更快?

问题2、如何比对验旧结果和明细录入的状态?
由于明细表是逐份录入,而验旧表是分段录入,对号码连续且状态相同的fa piao只录入一笔(即便是十几本fa piao,只要是“号码连续且状态相同”,也只录入一笔)。
现在要对这两个表的fa piao状态进行比对,如在【fa piao明细】表中的第58行,代码为165000521311、号码是1088的这一张fa piao(每一张fa piao都是通过fa piao代码和fa piao号码来唯一确定,即fa piao代码不同时,fa piao号码可以相同),在【fa piao验旧】表中查到其对应于第2行,属于1086~1090的号段,于是“验旧结果”就应该是“填用作废”;进而判断“fa piao状态”和“验旧结果”是否相同,若相同,“比对结果”即为True。
如果数据量比较少,完全可以用循环的办法来逐行进行查找,但很显然效率不高,对于现在这样庞大的数据量来说,这种方法不知道要算多长时间才能算出结果?

另外,比对结束后,还要能给出【fa piao明细】表和【fa piao验旧】表的差集,即哪些piao已经验旧但还没有录入?
 下载信息  [文件大小:   下载次数: ]
点击浏览该文件:fa piao管理_ljb.table

[此贴子已经被作者于2010-1-31 16:05:08编辑过]
2楼
mr725 发表于:2010/1/31 19:49:00
没玩过这么大量的数据出来,问题太多,晕菜啊~     帮你顶~ 
3楼
菜鸟foxtable 发表于:2010/1/31 21:38:00
问题一:新建金额结算表,表通过字段“fa piao本号”进行关联,增加累计填开金额列。这样可以保存数据,且假如需要合计所有填开金额,只要基本查询语句就可做到:select SUM(累计填开金额) as 总填开金额 from 金额结算表

问题二:没看明白,帮顶。
4楼
mr725 发表于:2010/2/1 18:18:00
终于看懂了你的意思::::::::::::   呵呵.

如果是内部表的话, 应该没有问题的. 且你的fa piao验旧表可以不要, 需要时再用临时表计算显示.

再说,你sql库里那么多数据,当时输入时怎么没有处理呢?   其实, 累计填开金额 不要在库表中单独加这列,需要时临时计算可以的.

还有对后台数据不用去计算它们(除了谁发疯啦), 需要查看时,按fa piao本号调出来,再计算显示.这样简单了.
[此贴子已经被作者于2010-2-1 18:38:16编辑过]
共4 条记录, 每页显示 10 条, 页签: [1]

Copyright © 2000 - 2018 foxtable.com Tel: 4000-810-820 粤ICP备11091905号

Powered By Dvbbs Version 8.3.0
Processed in .14063 s, 3 queries.