讨论下：你碰到的业务系统中，报表统计功能如何组织
在很多业务系统中，往往涉及报表数据统计的功能，这些统计功能往往根据不同的行业、不同的分析角度而进行，不过，其相同点都是对业务明细数据根据需求进行各种统计汇总组合。这些功能在业务数据量较少的前期，一般没什么性能问题，但随着时间、业务的发展，数据量越来越多，而之前的一些速度很快的报表功能会变得越来越慢。这些现象估计有比较多人员在实际中碰到，所以，现在想看看各位日常中是如何解决这种问题的，最好包括从明细数据的组织、报表结果的数据如何组织、功能架构的原理逻辑等一系列的角度说明下。
  另外，在数据仓库、数据挖掘等领域，数据量那么大，类似上述的现象问题又是如何解决的？

  欢迎大家将实际中的上述类似问题的解决方案分享下，谢谢！

ps:
  可用分不多，倾我所能了。

------解决方案--------------------


建议网上搜索一下 OLTP, OTAP, ETL， 数据仓库的知识。 数据仓库和你所说的现在这种事务的操作数据库数据理今不同。

[color=#FFFFFF][/color]
------解决方案--------------------
是否能够再建立一个数据库。专门用于查询方面的工作。
------解决方案--------------------
关注中~~~
------解决方案--------------------
up！~
------解决方案--------------------

引用

1楼你误解我的意思了

我的意思是：
目前很多公司的业务系统，肯定有相关报表统计功能需求的，我想问的一般像这些功能大家平时都怎么去设计的。例如，某公司一个产品系统，一般都会在这个产品系统里附有按多个角度去“统计产品销售汇总”的统计分析功能，当产品记录、销售明细记录少时，直接对明细表进行统计，那肯定是没问题的，假如随着业务的发展，后来产品去到了几百万中，销售记录每天都有几千万条，这时，如果再像业务系统刚建立时直接对源明细表来进行统计的话，那这时肯定会大大影响这个产品系统的性能。

类似上面的案例，大家平时应该碰到很多，我就是想看看大家的解决方案？为什么要这样处理？

------解决方案--------------------


看你的系统有多小了。
如果你的客户不能忍受效率上的问题，则只能把数据预先提出来。

每天晚上跑个脚本，按照事先确定的颗度把数据整理出来，放到另外一个表中。这样早上用户上班的时候就可以进行分析了。

视情况而定，是否需要放到另外一个数据库中，分离的数据库会减小对在线事务数据的影响。
(以上的数据仓库中的一小部分概念，并不是让你去建一个真正的数据仓库)

至于，如果你的系统很小，直接在你的事务表中做查询用户可接受的话，那你当然可以什么都不用做。
------解决方案--------------------


你上面说了2种方案

只说了一种方案啊。第二种是什么？

但现在问题时，如果要考虑基于这个报表的汇总数据易于扩展呢（即从这个报表的汇总数据，很容易满足给其它一些统计功能利用）？

这个问题在数据仓库中有提到，如何规则你的数据粒度。总之是要找一个平衡。
------解决方案--------------------

引用

这样的话，如果要考虑易于扩展的话，那粒度上来说，是不是选择最小粒度来进行保存比较合适？但这样的话，那数据记录数可能就很多（跟明细记录差别不是太大了）。

------解决方案--------------------
版主~此贴可以设为推荐，让更多人参与讨论哦！
------解决方案--------------------


应人民群众要求，推荐！
------解决方案--------------------
mark
听听大家的看法!
楼主所提出的问题,也是我所困惑的
------解决方案--------------------
mark
------解决方案--------------------
很经典 值得学习
------解决方案--------------------
关注中~~~
------解决方案--------------------
根据报表所需要的查询，首先要对数据库进行优化，如建立索引什么的。
对大型的表，可根据需要定时将数据从表中取出，放到另外一个表中，专门供查询用，不影响事务的进行。
数据量再大的话，可以定期从数据库备份数据到另外一个数据库，查询这个数据库了。
如果再大的话，那就用DM和DW，用专门的DTS工具抽取数据，进行重新组织和处理了，就是所谓的数据仓库系统了。
------解决方案--------------------
1、这些业务系统大多是分年度进行分析统计的
2、可以用动态表的方式，表名+年度 形式，每年一套；这样可以解决你性能的问题
3、如果表数据量过大的话，可以考虑下采取表分区的形式，这样性能问题可解决部分
希望对你有帮助！！！
------解决方案--------------------
你不会是想用别的解决吧，数据仓库这里数据量大，有几个是在业务层解决的，都是在DB层。
------解决方案--------------------
具体的项目,具体的分析
------解决方案--------------------

------解决方案--------------------