怎樣報表資料庫

怎樣報表資料庫

進一步討論請參考 Er Evans 總結。  

如果我採用了 領域模型（ Domain Model 如何支援特定的 SQL 查詢呢？

領域模型可提供大力支援。但是現存的許多報表工具不支援領域模型，領域模型的要點之一就是應用資料身上新增重要的操作方法。如果你想為資料生成報表。都是直接用 SQL 與資料庫互動的該怎樣處置呢？

需要一份特別的報表常意味著恰當合理的需求沒被挖掘出來，首先要對這種特定報表的需求提出質疑。很多情況下。一旦用心深入分析，就會發現用報表其實很彆扭，不像你之前想得那麼合適，另外，基於領域模型寫程式碼也能輕鬆生成報表。很多情況下，真正的需求是快速生成報表，客戶並不關心報表到底是怎麼生成的總之不會想自己敲 SQL

有一些厲害的使用者偏偏喜歡直接用基於 SQL 報表工具。這種情況的一個好對策就是生成一個 “ 報表資料庫 ” 所謂報表資料庫，話也不能說得太絕對。儲存實際運算元據的資料庫外的另一個資料庫，基於領域模型編寫程式碼給它填充資料，因此從領域模型衍生出的資料也能填進去。這能帶來以下好處：

可以把領域模型衍生資料加到報表資料庫。

•     因為報表資料庫是隻讀的也就無需追求資料庫設計符合正規化。

•     資料庫的結構可以專門設計得便於生成報表。

•     開發團隊可以重構原運算元據庫，
  •     通過領域模型填充資料。而不影響報表資料庫。
  •     查詢報表資料庫不會影響原運算元據庫的效能。
  報表資料庫的缺點是需要堅持它資料不過時，時限問題可能很麻煩。最簡單的情況是深夜進行資料重填，很多報表用前一天的資料也能正常運轉，這種簡單方法就搞定了如果你需要更實時的資料，可以藉助訊息系統實現：對原運算元據庫的任何修改都會通過訊息傳送給報表資料庫。這種情況更復雜，但能保鮮資料。通常多數報表用不那麼新鮮的資料也無妨，假如確實需要最新資料，就要特別問題特別對待了

   

  檢視層面也無需追求正規化化，另一種變通方案是利用檢視。檢視封裝了實際運算元據。但它不能分開實際操作負載和報表查詢負載（還是一個庫）更嚴重的問題是被限制在可獲得的那些檢視上，無法再利用領域模型靈活的操作了

  許多人認為這類情況是面向服務構架（ SOA 目的之一。 雖然我通過一個領域模型的例子引出報表資料庫的但這種方法適用於任何需要封裝資料庫的情況。