在数据存储的早期，存储几GB信息需要一个实际的仓库来容纳所有服务器。如今，生活在一个USB驱动器作为促销物品的时代，它们可以存储等量的数据。数据专业人员的方法并没有跟上硬件取得的惊人进步。本文提出了一种简单的方法，利用这种硬件优势，以相对较少的努力，快速分析数TB的信息。如果使用的是相对较新的硬件，这将在现有SQL数据库上工作，无需任何额外的硬件、软件、ETL或复制技术。
传统的系统架构师喜欢将分析性OLAP查询和OLTP事务性查询分开。这通常是由于硬件和软件的限制。虽然有许多第三方框架用于分析数据，但SQL语言实际上可以处理大多数今天的业务需求和数据库。这种方法通常被称为关系OLAP或ROLAP。对于今天的大多数业务需求和数据库，没有必要将数据复制到像MDX这样的单独软件中。
虽然有幸生活在一个内存便宜且丰富的世界，但也有责任处理大量的数据。将使用日期聚合来压缩数据，使其能够适应系统内存，这仍然比旋转硬盘快几个数量级。现在64位系统已经很普遍，一个能够处理超过32GB内存的系统可以花费几千美元。使用基于日期的聚合，压缩后的结果可以放入系统内存中。
面对隐藏数据库复杂性给用户带来的挑战，许多BI供应商和顾问认为传统的SQL模型不够吸引人，无法证明他们的价格点。他们提出了专有的建模技术，以最大化查询性能以及计费小时数。今天，MDX已经成为一种标准的复杂数据建模方式。虽然MDX是一项了不起的技术，但很少有IT人员有耐心或精神力量去掌握MDX。如果有这样的宝石，请好好对待他们，因为他们昂贵且非常难以替代。当服务器只有32MB内存时，Cubes技术是唯一的选择，而今天的系统有近千倍的内存可用。现在，普通硬件可以在几秒钟内运行数十亿条记录，而不需要专用硬件，Cubes技术的吸引力大大减少，而巨大的成本使得投资值得怀疑。
进行聚合压缩将实现与使用MDX或Cubes技术相同的结果，但投资时间和资源要少得多。不是使用复杂的数据模型来缓存数据，而是以许多特定方式定义和维护，进行大范围的总体聚合。选择一个粒度级别（如天或小时），并以相同的方式压缩所有可报告的数据。每天可能有成千上万的交易，但可能只关心按天、月或季度报告。如果将数据聚合到每天的水平，像Izenda Reports这样的优秀报告前端可以让用户轻松地可视化和导航信息。这段代码展示了如何将所有日期应用到年度粒度。
SQL
DATEPART(year, OrderDate)
AS
Year
由于一年通常不够精细，但一天是，将不得不进行一些细化。由于没有DATEPART方法支持获取没有时间的完整日期，使用DATEDIFF和DATEADD做了一点技巧。不想要任何小于日常粒度的东西，因为这将减少通过聚合压缩数据的数量。请注意，这种方法不会压缩实际数据。相反，它创建了一个视图，占用的空间要少得多，可能在内存中提供很大的帮助。
SQL
DATEADD(D,
0
, DATEDIFF(D,
0
, OrderDate))
让以Northwind订单表为例。将创建一个视图，模拟一个更大的数据集（见其他文章）。创建一个视图，将所有记录聚合到每个维度的每一天的一行。
原始数据看起来像这样。有ShipCountry和ShipCity作为地理维度，OrderDate作为时间维度，OrderID和Freight作为将转换为度量的属性。
CREATE VIEW OrdersView AS
SELECT
ShipCountry,
ShipCity,
DATEADD(D,
0,
DATEDIFF(D,
0,
OrderDate)),
COUNT(OrderID), SUM(Freight)
FROM
dbo.Orders
GROUP BY
ShipCountry, ShipCity, CAST(FLOOR( CAST( OrderDate AS FLOAT ) ) AS DATETIME)