在大型表上计算任何数据的最佳选择是什么？

Question

场景如下：

有一个包含数百个业务的表，假设每个企业创建自己每天100至200行的数据。

例如，每个企业每天收到150份订单。这些数据记录在数据库中。

在每个月底，由于企业所创造的数据的大小会扩大数据库，我认为企业统计报告的结果会更长。

例如，A公司在月底产生了3000行数据，而B公司则产生了4000行数据。

到年底，A公司产生的行数将为36000行，B公司产生的行数将为48000行。

当企业想要查看他们的月收入和销售收入时，一个接一个地浏览84000行的数据库并计算所需的数据是没有意义的。因为我只给两个企业举了这个例子，想象一下如果有几百个呢？

我想出了一个解决方案，我想咨询一个逻辑解决方案，因为我不知道在大型应用程序中是如何制定解决方案的。

当企业生产每日数据时，我可以每天更新这份统计报告，方法是计算它们生成的数据，并将其保存在一个单独的表中。

到了月底，我想他可以很快找到相关的线，而不用翻阅数千行。

在大型表上计算任何数据的最佳选择是什么？

Answer 1

在方案中，84000条记录是一个不用担心的表，你可以用大多数关系数据库引擎很好地处理它。如果您谈论的是数百万条记录，那么您很可能希望查看数据仓库策略。SQL server有一个名为Analysis的工具，它可以获取数据并创建预计算的聚合，这样报表计算就更快了，我预计大多数数据库供应商都会有类似的内容。对于传输处理，这是您的原始数据库将使用什么(OLTP -联机事务处理)，您希望数据在第三范式。为了分析目的(OLAP -联机分析处理)，您需要去标准化数据，因为如果不需要跨多个表，聚合可以更快地完成。客户->地域->区域和变型->产品->类型->超型。