报表数据库


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

如果我采用了领域模型(Domain Model),如何支持特定的SQL查询呢?

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

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

话也不能说得太绝对,有一些厉害的用户偏偏喜欢直接用基于SQL的报表工具。这种情况的一个好对策就是生成一个“报表数据库”。所谓报表数据库,是存储实际操作数据的数据库外的另一个数据库,基于领域模型编写代码给它填充数据,因此从领域模型衍生出的数据也能填进去。这能带来以下好处:
  •     通过领域模型填充数据,可以把领域模型衍生数据加到报表数据库。
  •     因为报表数据库是只读的,也就无需追求数据库设计符合范式。
  •     数据库的结构可以专门设计得便于生成报表。
  •     开发团队可以重构原操作数据库,而不影响报表数据库。
  •     查询报表数据库不会影响原操作数据库的性能。
报表数据库的缺点是需要保持它的数据不过时,时限问题可能很麻烦。最简单的情况是在深夜进行数据重填,很多报表用前一天的数据也能正常运转,这种简单办法就搞定了。如果你需要更实时的数据,可以借助消息系统实现:对原操作数据库的任何修改都会通过消息传递给报表数据库。这种情况更复杂,但能保鲜数据。通常多数报表用不那么新鲜的数据也无妨,假如确实需要最新数据,就要特别问题特别对待了。

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

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

进一步讨论请参考Eric Evans的总结。 
发布了10 篇原创文章 · 获赞 0 · 访问量 40万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览