怎样报表数据库

怎样报表数据库

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

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

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

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

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

可以把领域模型衍生数据加到报表数据库。

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

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

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

   

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

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