记录各个产品每日的结余情况,
形式如:
20070501,item1,59
20070501,item2,122
20070501,item3,14
20070502,item1,36
20070502,item2,100
每一产品每日都记录余额
产品目前约有2000个.
问题有
1.我是为了方便计算任意起始期间任意item的余额的和.请问有在设计上有无更好的设计?
之所以每产品每日的记录,而没去记录发生额以推算,是为了以空间换时间.
不知这样合理否.
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算.
请问有何优化方法?
比如索引如何建,或者其他的设置.
或是否需要计算和插入时去掉索引，完成后再创建(如要实现这种功能,可以在存储过程中实现么?).
希望各位指点
诚挚感谢.
5 个解决方案
#1
1.我是为了方便计算任意起始期间任意item的余额的和.请问有在设计上有无更好的设计?
你在表力面加一个时间字段 名称：f4 类型:datetime ，对这个字段建立索引，对 item 也建立索引
select sum(余额) from table1 where f4>=开始时间 and f4<=结束时间 and item=item2
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算
这个不好说，要看你的具体应用，求和查询的使用是否频繁 ，并发查询是多少
不过不明白，一年365天 365*2000=73万 ，你怎么有175万数据啊
#2
1.我是为了方便计算任意起始期间任意item的余额的和.请问有在设计上有无更好的设计?
之所以每产品每日的记录,而没去记录发生额以推算,是为了以空间换时间.
不知这样合理否.
－－－
索引
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算.
请问有何优化方法?
－－－
每日的计算为什么前三个月的有关，进行年度结转
之所以每产品每日的记录,而没去记录发生额以推算,是为了以空间换时间.
不知这样合理否.
－－－
索引
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算.
请问有何优化方法?
－－－
每日的计算为什么前三个月的有关，进行年度结转
#3
回arrow_gx:
Sorry,库存表确实是70多万
我作count的时候是对的应收余额表了，是同样的策略.
具体应用的话，这个表应该只算个中间结果,会在每夜处理中在这个表基础上进一步计算出周转天数后提供给客户查询，计算中多用于时间between的sum,因此对这个表进行直接查询的前端应用不多.
回happyflystone:
因为存在改单的情况，所以我假设3个月前的单不会做更改,3个月可以变为6个月或者更长，不想把增量控制做得太复杂.
另外，索引是对ctimeid 和item 分别建的好么?
btw,仍是那个问题，删和插数据时要drop index,这可以在存储过程里作么?
谢谢两位回答.
Sorry,库存表确实是70多万
我作count的时候是对的应收余额表了，是同样的策略.
具体应用的话，这个表应该只算个中间结果,会在每夜处理中在这个表基础上进一步计算出周转天数后提供给客户查询，计算中多用于时间between的sum,因此对这个表进行直接查询的前端应用不多.
回happyflystone:
因为存在改单的情况，所以我假设3个月前的单不会做更改,3个月可以变为6个月或者更长，不想把增量控制做得太复杂.
另外，索引是对ctimeid 和item 分别建的好么?
btw,仍是那个问题，删和插数据时要drop index,这可以在存储过程里作么?
谢谢两位回答.
#4
1、另外，索引是对ctimeid 和item 分别建的好么?
是的，不过你最好贴出你的语句，这样才好分析用什么索引
2、删和插数据时要drop index,这可以在存储过程里作么
这个操作是可以在存储过程里面实现的，但是如果数据量大的话，是很费时间的，不明白你为什么要这样做
是的，不过你最好贴出你的语句，这样才好分析用什么索引
2、删和插数据时要drop index,这可以在存储过程里作么
这个操作是可以在存储过程里面实现的，但是如果数据量大的话，是很费时间的，不明白你为什么要这样做
#5
每天每个产品做一个我觉得不太好吧
我们是每个结帐月每个产品一个结余,未结帐月份一个余额,这刚好和财务结帐一样,
在目前机器的运算能力下,根据上一月份的结余和当前月份的发生流水帐实时计算任意一天的余额所花时间不会太久
(按你2000多个产品我们的系统大概10秒内就可以了,当然要看你的服务器配置了,我们一般是扣肉双核1.8G,1G内存)
当然如果你的客户对于这个时间都不能接受就没办法了(其实客户很多时候都是只需要查询即时库存的,对于这个问题可以直接查询
当前未结帐月份库存就可以了)
我们是每个结帐月每个产品一个结余,未结帐月份一个余额,这刚好和财务结帐一样,
在目前机器的运算能力下,根据上一月份的结余和当前月份的发生流水帐实时计算任意一天的余额所花时间不会太久
(按你2000多个产品我们的系统大概10秒内就可以了,当然要看你的服务器配置了,我们一般是扣肉双核1.8G,1G内存)
当然如果你的客户对于这个时间都不能接受就没办法了(其实客户很多时候都是只需要查询即时库存的,对于这个问题可以直接查询
当前未结帐月份库存就可以了)
#1
1.我是为了方便计算任意起始期间任意item的余额的和.请问有在设计上有无更好的设计?
你在表力面加一个时间字段 名称：f4 类型:datetime ，对这个字段建立索引，对 item 也建立索引
select sum(余额) from table1 where f4>=开始时间 and f4<=结束时间 and item=item2
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算
这个不好说，要看你的具体应用，求和查询的使用是否频繁 ，并发查询是多少
不过不明白，一年365天 365*2000=73万 ，你怎么有175万数据啊
#2
1.我是为了方便计算任意起始期间任意item的余额的和.请问有在设计上有无更好的设计?
之所以每产品每日的记录,而没去记录发生额以推算,是为了以空间换时间.
不知这样合理否.
－－－
索引
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算.
请问有何优化方法?
－－－
每日的计算为什么前三个月的有关，进行年度结转
之所以每产品每日的记录,而没去记录发生额以推算,是为了以空间换时间.
不知这样合理否.
－－－
索引
2.目前11个月的数据记录是175万行.
机器环境是,ibm pc server,2 CPU,4G内存,sql server 2K.这样扩张下去2-3年内会否有性能问题?
为了应对修改之前的单据的变化,我每日计算时，删除最近3个月的记录并重算.
请问有何优化方法?
－－－
每日的计算为什么前三个月的有关，进行年度结转
#3
回arrow_gx:
Sorry,库存表确实是70多万
我作count的时候是对的应收余额表了，是同样的策略.
具体应用的话，这个表应该只算个中间结果,会在每夜处理中在这个表基础上进一步计算出周转天数后提供给客户查询，计算中多用于时间between的sum,因此对这个表进行直接查询的前端应用不多.
回happyflystone:
因为存在改单的情况，所以我假设3个月前的单不会做更改,3个月可以变为6个月或者更长，不想把增量控制做得太复杂.
另外，索引是对ctimeid 和item 分别建的好么?
btw,仍是那个问题，删和插数据时要drop index,这可以在存储过程里作么?
谢谢两位回答.
Sorry,库存表确实是70多万
我作count的时候是对的应收余额表了，是同样的策略.
具体应用的话，这个表应该只算个中间结果,会在每夜处理中在这个表基础上进一步计算出周转天数后提供给客户查询，计算中多用于时间between的sum,因此对这个表进行直接查询的前端应用不多.
回happyflystone:
因为存在改单的情况，所以我假设3个月前的单不会做更改,3个月可以变为6个月或者更长，不想把增量控制做得太复杂.
另外，索引是对ctimeid 和item 分别建的好么?
btw,仍是那个问题，删和插数据时要drop index,这可以在存储过程里作么?
谢谢两位回答.
#4
1、另外，索引是对ctimeid 和item 分别建的好么?
是的，不过你最好贴出你的语句，这样才好分析用什么索引
2、删和插数据时要drop index,这可以在存储过程里作么
这个操作是可以在存储过程里面实现的，但是如果数据量大的话，是很费时间的，不明白你为什么要这样做
是的，不过你最好贴出你的语句，这样才好分析用什么索引
2、删和插数据时要drop index,这可以在存储过程里作么
这个操作是可以在存储过程里面实现的，但是如果数据量大的话，是很费时间的，不明白你为什么要这样做
#5
每天每个产品做一个我觉得不太好吧
我们是每个结帐月每个产品一个结余,未结帐月份一个余额,这刚好和财务结帐一样,
在目前机器的运算能力下,根据上一月份的结余和当前月份的发生流水帐实时计算任意一天的余额所花时间不会太久
(按你2000多个产品我们的系统大概10秒内就可以了,当然要看你的服务器配置了,我们一般是扣肉双核1.8G,1G内存)
当然如果你的客户对于这个时间都不能接受就没办法了(其实客户很多时候都是只需要查询即时库存的,对于这个问题可以直接查询
当前未结帐月份库存就可以了)
我们是每个结帐月每个产品一个结余,未结帐月份一个余额,这刚好和财务结帐一样,
在目前机器的运算能力下,根据上一月份的结余和当前月份的发生流水帐实时计算任意一天的余额所花时间不会太久
(按你2000多个产品我们的系统大概10秒内就可以了,当然要看你的服务器配置了,我们一般是扣肉双核1.8G,1G内存)
当然如果你的客户对于这个时间都不能接受就没办法了(其实客户很多时候都是只需要查询即时库存的,对于这个问题可以直接查询
当前未结帐月份库存就可以了)