2011-11-14 32 views
0

我正在实施一个基本的星型模式来为我的公司提供购买报告。我们的事实表总结了4个维度,并且汇总了每日,每周,每月和每年的总计。PHP中简单数据仓库的日期之间的间隔

该代码当前知道如何处理单日,数周,数月和数年的报表。下一步是实施任意日期范围报告。提供一个范围,目标是了解这两个日期之间的总年数,月份,周数和天数,并拉到合适的记录来计算总数。问题是我们需要确定两个日期之间的每个整个粒度周期的计数,而不仅仅是经过的时间量。

例如,在'2009-06-29'和'2011-06-29'之间已经过了2年,但是我们需要知道这个范围包括一整年(2010),十一个月(Jan- May/10 & Jul-Dec/09)和58天(Jun 1-29/09 & Jun 1-29/11)。

从这个结果中,我们可以从70个粒度周期中提取已经汇总的记录,合并并呈现总计。

我一直在编写测试代码来确定将日期范围分解为其组成部分的最佳方式,但是由于我怀疑我正在过度使用此过程,因此我正在退后一步。目前的草案作为:

  1. 填入“datesToParse”数组与初始日期范围。
  2. 确定日期之间是否存在一个或多个满年。
    • 对于日期之间的每一年,从日期范围中删除该期间,并将该年份之前的“期间”和“期间之后”分为两个新的日期范围。
    • 在“datesToParse”堆栈上推送两个新的日期范围。
    • 重复
  3. 当所有可能的几年已经从“datesToParse”数组中删除,重复上述过程数月,周,日。

理论上这应该递归地将初始日期范围缩减为全年,月,周和天的集合。

有没有更好的方式来做到这一点?这看起来像是之前已经解决了很多次的问题。

+1

你能不能简单地选择那个时期的所有聚合每日总数,并将它们加在SQL中? – liquorvicar

回答

1

我不明白你为什么要实现这样一个复杂的解决方案,通常的实现是只有一个事实表的数据在最低粒度级别(每天在你的情况下)和简单的SUM()up根据需要查询您的查询中的措施。

这是非常简单的实施和维护和查询非常容易编写(或从您的报告工具生成)。这不适合你吗?你有多少数据量?你是否将日期作为维度实现(希望是)或作为事实表中的值?您是使用报告工具(SSRS,Cognos,Business Objects)还是滚动您自己的查询?

如果你正在考虑性能问题,这是很普遍的DWH演变是这样的:

  1. 实现单事实表(如上所述)
  2. 添加大量数据
  3. 发现性能问题,因为数据量增加
  4. 提高索引
  5. 实现表分区
  6. Impleme nt OLAP

您的解决方案听起来有点像自制的OLAP实现,但尚不清楚为什么需要它。如果你的数据量小到中等,你可能可以很好地管理它索引和分区。如果它很大,那么您可能会考虑使用OLAP和专门的报告工具,这将是一个更广泛的问题。但是你没有提供关于你的环境或要求的很多信息,所以我可能在这里不受欢迎。