在某个查询操作中,需要算出商品的订货数之类的。而算订货数的时候需要一些逻辑,根据以前的卖数来决定订多少货,以及给用户一个建议需要订多少货。用户可以根据店铺号或者再加上商品类别、商品条形码之类的来查看商品的这些信息。因为某一个店铺存在哪一个服务器上是不一定的,所以首先要根据店铺号判断该店铺在哪个服务器上,然后再根据其他条件来查询。商品有十几万种,用户可以同时选择最多5个店铺来抽数据,以前的系统抽一个店铺就需要挺长时间,接近2分钟。主要是算订货数之类的太麻烦,涉及到很多表,还要经过很多计算。
我想问一下,在每次操作中,我先根据用户选择的店铺而把该店铺里所有的商品取出来放在内存中,再把和这些商品有关的也全都取出来放在内存中。假设十几万条商品信息存放在内存中,对于512的内存来说会不会不够用。其他用户也可能进行同样的操作,我应该怎么保证内存中的数据和数据库中的数据同步?以前的系统是把所有的逻辑都写在一个大存储过程中执行的,存储过程只要接受用户选择的查询条件。我个人感觉那样会影响速度,因为其中涉及到很多临时表,还有对临时表的更新等,而且每次用户查询都要重新去读取数据。
请各位大虾给个好的建议。这是winform开发。
会慢,但是效率还是可以忍受的,不会造成太大影响
用存储过程速度还可以啊!我们的项目也是数据量很大但是也都可以,我建议你优化一下你的存储过程。
数据有十几万条,而且还关联了N多表,看来512M内存小了点。要优化速度首先要找到性能瓶颈,才能有针对性。还有一种方法是在夜间计算最新的订货数量并保存,第二天全天都用这个已经算好了的数据。毕竟有些数据并不要求必须是实时更新的。
不知道可不可以做个分析结果的缓存,,,如果数据有更新,那么就计算更新部分的数据,然后再缓存起来
才几十万条数据因该不是什么问题
通过索引应该就能解决,应该还比较快
只要数据不上百万 应该查询都不应该倒分钟的级别
至于优化数据在web里面一般是有2种做法
一种就是缓存 一种就是中间表
缓存就不用说了 一段时间更新一次
中间表就是将今天的数据和以往的数据分开存放
然后以往的数据每天做一个统计表
然后统计表加上今天当前的数据,当然就是所有的数据了
由于今天的数据是很小的
而之前的数据通过作业每天进行汇总放到统计表里所以也不大
然后用程序处理 将2个记录加起来就ok了
我也经验不多,说说自己的看法啊.
其实我是比较同意 小老鼠的 临时表也可以建索引,写存储过程时尽管基于集合的操作,这样效率会高一些,如果不行,还可以写得CLR存储过程试试,然后可以应用缓存策略.就算是缓存也应该在服务器端啊.在客户端是不是有点不好控制.
最好还是采用一些监控机制看看到底是哪个语句,哪个过程执行时间长.然后看看能不能修改它.十几万数据如果是公网在网络传送是不是也要花挺长时间啊.