报表数据库

原文： ReportingDatabase   设计      2004年4月2日            Bliki 索引

如果我采用了 领域模型（Domain Model） ，如何支持特定的SQL查询呢？

领域模型的要点之一就是在应用数据身上添加重要的操作方法。如果你想为数据生成报表，领域模型可提供大力支持。但是，现存的许多报表工具不支持领域模型，它们都是直接用SQL与数据库交互的。该怎样处理呢？

首先要对这种特定报表的需求提出质疑。很多情况下，需要一份特别的报表常意味着恰当合理的需求没被挖掘出来，一旦用心深入分析，就会发现用报表其实很别扭，不像你之前想得那么合适，另外，基于领域模型写代码也能轻松生成报表。很多情况下，真正的需求是快速生成报表，客户并不关心报表到底是怎么生成的，总之不会想自己敲SQL。

话也不能说得太绝对，有一些厉害的用户偏偏喜欢直接用基于SQL的报表工具。这种情况的一个好对策就是生成一个“报表数据库”。所谓报表数据库，是存储实际操作数据的数据库外的另一个数据库，基于领域模型编写代码给它填充数据，因此从领域模型衍生出的数据也能填进去。这能带来以下好处：

•     通过领域模型填充数据，可以把领域模型衍生数据加到报表数据库。

•     因为报表数据库是只读的，也就无需追求数据库设计符合范式。

•     数据库的结构可以专门设计得便于生成报表。

•     开发团队可以重构原操作数据库，而不影响报表数据库。

•     查询报表数据库不会影响原操作数据库的性能。

报表数据库的缺点是需要保持它的数据不过时，时限问题可能很麻烦。最简单的情况是在深夜进行数据重填，很多报表用前一天的数据也能正常运转，这种简单办法就搞定了。如果你需要更实时的数据，可以借助消息系统实现：对原操作数据库的任何修改都会通过消息传递给报表数据库。这种情况更复杂，但能保鲜数据。通常多数报表用不那么新鲜的数据也无妨，假如确实需要最新数据，就要特别问题特别对待了。

另一种变通方案是利用视图。视图封装了实际操作数据，在视图层面也无需追求范式化，但它不能分开实际操作负载和报表查询负载（还是一个库），更严重的问题是你被限制在可获得的那些视图上，无法再利用领域模型灵活的操作了。

虽然我是通过一个领域模型的例子引出报表数据库的，但这种方法适用于任何需要封装数据库的情况，许多人认为这类情况是面向服务构架（SOA）的目的之一。

进一步讨论请参考 Eric Evans的总结。