现在的统计表是从各个流程获取相应的数据进行统计的(从订单,出货,卖出,返品,出货计划,生产计划等几个表),由于各个基础表数据量大,响应速度慢,整个界面拉取速度需要十几秒到1,2分钟,同时现在需要统计的数据变得越来越多,因此想要设计个统计表,考虑过以下方案1:使用物化视图,由于物化视图也是初步的了解,并未在真实业务中真正使用过,现将认识表述如下:物化视图不适合统计(GROUP BY等),而且统计都是多级统计,嵌套子查询,视图,函数....,GOOGLE了下物化视图的使用,几乎没有什么案例和介绍,所以不知实际如何使用.不知是否理解正确,敬请指教.2:使用JOB定时执行,每天晚上统计一次,写进月临时表,然后根据日期每次查询的时候统计当前变动信息.(此方案觉得蛮好,但是客户操作多了个查询之前进行统计操作,更主要的是我认为不太符合整个应用设计准则,虽然耦合性不高,但是感觉此种做法总是有问题,确也说不出到底对应用有什么影响...郁闷....)3:重新设计统计实体表,此种获取统计信息方式我考虑了有2种:
(1)在之前的每个流程(下订单,发货,卖出..)在程序段,实现往统计表写入相应的基础信息,此种做法相当于做了数据冗余,并没有起到统计作用,需要再次对该表进行统计
(2)使用基础表触发器,触发器写入变动的数据到统计信息表,并且进行相应的统计(更新,删除操作),但是需要对多个基础表进行触发器增加,没有做过如此大规模的变动,不知道是否会对整个应用产生什么影响4:数据仓库(只有纯概念)呵呵,字数的多了点,希望大家不要晕.....

解决方案 »

  1.   

    数据仓库不太可能,只是想实现类似的功能模块,公司还不是ERP呢,还是MES和MIS信息,所以可以任我设计和修改,,呵呵,当然前提是改善,而不是破坏,,各位大大,尽管说,先谢谢大家了
      

  2.   

    楼主应该是制造行业的吧?你当前的server load情况怎么样?当前你认为最大的问题是什么?从专业角度来描述,而不是说“慢”。你的语句是什么形式?源表的增删改情况又怎么样?
    你的report要求的实时性又是多高?。
      

  3.   

    服务器负载的北京DBA负责的,不过我从应用和数据量的角度以及应用使用频率和人数感觉负载不是很大
    我现在最大的问题是解决慢,以及需要统计信息的实体表,之前都是通过查询直接得到的没有实体表
    实时性要求很高,要求输入完订单,或者输入生产计划,立刻可以得到该信息
      

  4.   

    赞成使用JOB日结,月结写入中间表,
    将密集计算和查询分散,间接提高统计性能。
      

  5.   

    如果用job,不就达不到实时要求了?还是?。。
      

  6.   

    Gerrard 说:
     JOB 
     我这里就这么用的
     每日跑一遍汇总表 
    ℉orёvēя 说:
     谢谢,兄弟
    Gerrard 说:
     用了2年多了~ 
     物化视图..适合多表join ~ 并且关系不复杂的情况下使用
     你的第三个是不可取的~ 
    1. 费劲,不觉得这么做成本很高吗?
    ℉orёvēя 说:
     是啊,我觉得成本很高,可是对于系统来说似乎更加有利
    Gerrard 说:
     2.一堆触发器,debug累不累? 万一放生产上去,发现出问题了,你会手忙脚乱的 假设是高并发系统,那简直就是玩命~
    ℉orёvēя 说:
     用JOB,感觉是最好的,耦合性非常低,可是整个设计,感觉需要考虑太多东西了
    Gerrard 说:
      job 跑~ 很舒服 爱怎么跑怎么跑 业务变动的时候 改一下job,或是改改store proc~ 
    半夜的run一下,啥数据都有了
     并且这就属于数据仓库里的ETL概念
    ℉orёvēя 说:
     可是实时性是有要求的呢,表是设计成永久和临时的?最初我想设计两个表,一个表保存过程数据,即每天都变动的数据,一个保存上个月的数据
    ℉orёvēя 说:
     物化视图我不太了解,研究了好几天了,没有什么头绪 啊,感觉不太合适...
    Gerrard 说:
      不过 你可以深入调查下 ~ 是否真的有必要实时...你应该是汇总 然后统计出报表的吧?
    姓和名上(脱机) 说:
     按照分析型应用和操作性应用共存的通用方案处理。
    Gerrard 说:
     一般情况 这样的汇总 ~ 基本不需要实时的~ ℉orёvēя 说:
     是啊,我也觉得实时性要求不需要太高,可是业务人员说需要实时得到该信息导出EXCEL给总部
    Gerrard 说:
     多表 数据海量 关系复杂~ 且大量计算 的最好解决方案应该是~ 数据仓库+内存库
     oracle 和IBM 都有相关的解决方案...
     IBM的有一个 汉庭酒店的案例..全国200多家酒店的整合~ 实时调整数据 实时汇总+实时反应回各个数据库~
    雪 说:
     谢谢!
    姓和名上(脱机) 说:
     我也欢迎下。
    ℉orёvēя 说:
     有链接么.那个例子
    Gerrard 说:
     - -无 
     ...今年..和他们的人 讨论方案时 ~ 他们侃的 
    ℉orёvēя 说:
     看来只有JOB来做了
    Gerrard 说:
     嗯 ~一天run 1次/2次 ~ 第二天早上让领导看看报表就好了嘛~ :D  
    雪 说:
     我遇到的问题和你们讨论的有些类似,我就是做了个job,然后早上6点那样执行
    姓和名上(脱机) 说:
     在外部写一个服务,可以触发job的执行,然后把服务集成到应用中,实现实时。
    ℉orёvēя 说:
     方案容易定啊,统计实体表设计起来有难度啊,.....
    Gerrard 说:
    其实不难,但是会消耗你大量时间~ :D 
    姓和名上(脱机) 说:
     如果整体数据量不大,可以采用内存数据库。或者nosql技术。
    ℉orёvēя 说:
     Gerrard ,是啊,很消耗时间,
     数据量倒是不的很大,一个月订单没有多少,统计完的数据也就一两百条
     列蛮多.一两百列
      

  7.   

    没有,我在考虑几个方案哪个的最适合的,综合大家都意见和整个业务功能的工作量,决定使用JOB了,大家祝福我吧,希望在离职前可以完成此项重大改革,:-)
      

  8.   

    存储过程+JOB
    每晚统计一次将结果保存在一张中间表里,做好详细的元数据
    第二天的统计根据元数据再结合统计后的数据更新可快速得出实时结果
    这样做还可以快速得到某历史点统计情况!
      

  9.   

    我以前处理过这样的 只有JOB最适合了  物化试图对复杂统计不实用  数据仓库那个不是咱开发人员能决定的