请原谅我，如果已经问过这个问题（我对数据仓库/ BI知之甚少，还没有掌握关键词）。
我有一个每天增加超过10万行的表，每行有一个时间戳和有关项目的多个信息（尺寸，重量，颜色等）。在此期间后，个人数据可能有用一个月左右，我们只对聚合感兴趣。我有一个专用软件，可以更详细地显示各行，并主要使用PowerPivot来满足我的报告需求。
我可以提出一个SQL查询，每天填充一个新表： 我会在每个小时/项目/批次中有一行，我会总结信息（sum / average / stddev / etc.）
在一天内我的脚本将启动并运行，我可以使用powerpivot对抗这个新表。这一切都在我感到舒服的地方：普通的旧SQL。
从我收集的关于DataWarehouse和BI的一些信息中，我要做的事情听起来很像创建维度和事实。因此，我的问题是：值得进一步调查这个方向（BI）或者因为我的问题相对简单，我会更好地留在关系数据库中。
N.B。正在生成的报告通常与另一个数据库相关联，以生成更有意义的信息。 Powerpivot完成的任务。
答案 0 :(得分：3)
数据仓库通常在关系数据库中实现，因此您现有的技能仍然可用。
鉴于您对数据仓库的维度/事实表方法表示了兴趣，通常认为这种方法的规范书籍是：
（前者有更多的技术重点，而后者从更广泛的生命周期管理角度来看待主题。）
实施DWH可能非常耗时，因此即使您决定构建DWH，也可能需要继续使用现有方法。
答案 1 :(得分：2)
好消息：听起来你已经拥有了一个数据仓库。 “数据仓库”是一个非常通用的术语，没有真正的正式定义 - 它几乎意味着你想要它。
普遍接受的特征是：
听起来你已经在做所有这些了。如果没有业务要求需要改变，我会保持原样。如果您的业务用户要求创建自己的查询，使用不同级别的聚合，过滤或粒度，则可以采用星型模式。
答案 2 :(得分：1)
最有效的解决方案是那些简单，足以满足现有需求并保持可用技能的解决方案。
我同意这种方法适用于您的情况，如果它提供您需要的报告和信息，那么它的价值就是从这种方式开始的。如果您以后需要更复杂的功能，那么您可以选择更复杂的BI