數據集市 - 創建多個數據庫或合併為一個？

以此為例（圖片取自Google）：

Purchasing所有數據管道圖都顯示每個不同的業務單元或特定工作範圍（在本例中為、Sales、 ）都有多個數據集市Inventory。

鑑於以下兩個選項：

選項 A：

car-db
|_ Databases
   |_ carDataMarts
      |_ dbo.fact_purchase_x
      |_ dbo.dim_purchase_y
      |_ dbo.dim_purchase_z
      |_ dbo.fact_sales_x
      |_ dbo.dim_sales_y
      |_ dbo.dim_sales_z
      |_ dbo.fact_inventory_x
      |_ dbo.dim_inventory_y
      |_ dbo.dim_inventory_z

選項 B

car-db
|_ Databases
   |_ car_purchase_DataMart
      |_ dbo.fact_purchase_x
      |_ dbo.dim_purchase_y
      |_ dbo.dim_purchase_z
   |_ car_sales_DataMart
      |_ dbo.fact_sales_x
      |_ dbo.dim_sales_y
      |_ dbo.dim_sales_z
   |_ car_inventory_DataMarts
      |_ dbo.fact_inventory_x
      |_ dbo.dim_inventory_y
      |_ dbo.dim_inventory_z

1. 該圖將如何轉化為數據集市的實際實施（選項 A 或 B）？
2. 選項 A 和 B 在性能或可用性方面應該存在某種差異，如果是，這些差異是什麼？

PS：使用 MS SQL

請記住，Google 的這個範例是關於數據倉庫/OLAP 設計實現的，它非常適合報告（通常是聚合性質的），特別是使臨時報告對消費者最靈活。但是，如果您計劃在其之上建構可以讀取單個行並將數據寫回表的應用程序，那麼對於 OLTP 系統來說，這不是一個理想的設計。

1. 該圖將如何轉化為數據集市的實際實施（選項 A 或 B）？

該圖在技術上轉換為選項 B，因為它為每個數據集市使用數據庫的符號。但對於這個具體的例子，我不一定同意這種類型的設計，因為數據可能在這些數據庫之間有很強的關係。

Sales, Purchasing, 和Inventory通常是密切相關的，並且很可能希望同時報告，即使從 OLAP 的角度來看也是如此。雖然將事物分離到不同的數據庫中不一定是一件壞事，但對於這種高度相關的數據庫對象來說並沒有多大意義，而且在 SQL Server 中這樣做也有一些小缺點。

一個缺點是您需要在每個數據庫中單獨管理安全性，並且需要為需要同時從多個域查詢對象（例如Salesvs Purchasing）的使用者進行適當的設置。因為即使您在數據庫中創建了一個從Sales數據庫中引用表的視圖，除非他們在兩個數據庫中都Purchase具有讀取權限，否則任何人都無法使用該視圖。有一種替代解決方案可以解決此問題，稱為跨數據庫所有權連結，但通常強烈建議不要啟用此功能。

相反，我會親自將這 3 個域（Sales、Purchasing和Inventory）放在同一個數據庫中，但每個域都在自己的架構下，如下所示：

car-db
 |_ Database
   |_ carDataMarts
      |_ purchasing.fact_x
      |_ purchasing.dim_y
      |_ purchasing.dim_z
      |_ sales.fact_x
      |_ sales.dim_y
      |_ sales.dim_z
      |_ inventory.fact_x
      |_ inventory.dim_y
      |_ inventory.dim_z

這允許您按域組織事物，並且如果需要，您可以按域在架構上按域在粒度級別管理權限，但您不需要這樣做，也可以在數據庫級別一起管理它們。

2. 選項 A 和 B 在性能或可用性方面應該存在某種差異，如果是，這些差異是什麼？

我不相信上述任何選項之間在性能方面存在任何差異（我的建議使用模式是選項 C）。在這方面，SQL Server 並不真正關心您是否跨數據庫或模式查詢對象。在可用性方面，我會推遲到我在前面的段落中討論過的關於管理權限的內容。

引用自：https://dba.stackexchange.com/questions/316378