数据聚合 - 日常 SQL 脚本与数据仓库答案

【问题标题】：Data Aggregation - Daily SQL Script vs Data Warehouse数据聚合 - 日常 SQL 脚本与数据仓库
【发布时间】：2012-03-23 12:54:10
【问题描述】：

如果有人问过这个问题，请原谅（我对数据仓库/BI 知之甚少，还没有掌握关键字）。

我有一个每天增长超过 100 000 行的表，每行都有一个时间戳和关于一个项目的多个信息（尺寸、重量、颜色等）。在我们只对聚合感兴趣的这段时间之后，单个数据可能会在大约一个月内有用。我有一个专用软件，可以更详细地显示各个行，并且主要使用 PowerPivot 来满足我的报告需求。

我可以想出一个每天填充一个新表的 SQL 查询：我将在其中为每个小时/项目/批次设置一行，我会总结信息（总和/平均/标准差/等）

一天之内，我的脚本就会启动并运行，我可以对这个新表使用 powerpivot。所有这一切都留在我舒适的地方：普通的旧 SQL。

从我收集到的关于 DataWarehouse 和 BI 的少量信息来看，我将要做的事情听起来很像创建维度和事实。因此，我的问题是：是否值得在这个方向（BI）进一步调查，或者由于我的问题相对简单，我最好留在关系数据库中。

注意正在生成的报告通常与另一个数据库链接，以生成更有意义的信息。 Powerpivot 可以很好地完成任务。

【问题讨论】：

【解决方案1】：

数据仓库通常在关系数据库中实现，因此您现有的技能仍然可以使用。

鉴于您已经表达了对数据仓库的维度/事实表方法的兴趣，关于这种方法的规范书籍通常被认为是：

（前者更侧重于技术，而后者则从更广泛的生命周期管理角度处理该主题。）

实施 DWH 可能很耗时，因此即使您决定构建 DWH，也可能值得继续使用现有方法。

【讨论】：

如果我能接受所有答案，我会接受的，因为他们都提出了帮助我做出决定的不同方面（现在让我们保持简单）。但是，由于这篇文章将我指向更多阅读内容，因此我将继续接受这篇文章。谢谢

【解决方案2】：

好消息：听起来您已经拥有一个数据仓库。 “数据仓库”是一个非常通用的术语，没有真正的正式定义——它几乎意味着你想要的任何东西。

普遍接受的特征是：

听起来你已经在做所有这些了。如果没有需要更改的业务需求，我会保持原样。如果您的业务用户要求创建自己的查询，使用不同级别的聚合、过滤或粒度，那么星型模式可能是要走的路。

【讨论】：

【解决方案3】：

最有效的解决方案是简单、足以满足现有需求并保持在可用技能范围内的解决方案。

我同意这种方法适用于您的情况，如果它提供了您需要的报告和信息，那么它值得以这种方式开始。如果您以后需要更复杂的功能，那么您可以选择更复杂的 BI

【讨论】：