物理部署數據集市的最佳實踐是什麼？
我們公司才剛剛開始涉足商業智能。我們有一些架構師正在設計我們的數據倉庫和數據集市。他們對兩種設計都使用星型模式。
架構師表示，他們用於集市的設計是相同的，我們只需要它的“另一個副本”供任何客戶希望查詢他們的集市，並且每個集市的數據可能不同。
我們只有一個市場開始。這是一個 AIX LPAR、一個 DB2 數據庫實例和一個具有一個模式的數據庫。
現在我們有另外三個數據集市的請求。最佳做法是什麼？這些應該是同一數據庫中的不同模式嗎？每個集市應該是同一實例中的單獨數據庫嗎？我們應該有單獨的數據庫、單獨的實例嗎？
從物理部署和維護的角度來看，這裡的最佳實踐是什麼？或者使用什麼準則來定義什麼時候應該是哪個選項？
聽起來您正在尋找與多租戶架構相似（如果不相同）的東西。
在多租戶架構中，所有租戶（客戶、客戶）共享一些東西。他們可能隻共享伺服器和 dbms，每個租戶都獲得一個私有數據庫。或者他們可能共享數據庫，每個租戶都獲得一個私有模式。或者他們可能共享表，其中每個表中的每一行都帶有一個租戶標識符。
所以有相當廣泛的選擇。其中每一個都可能被認為是某些應用程序的最佳實踐，而對於其他應用程序來說則是最差的實踐。
您的架構師似乎在考慮“每個客戶一個數據庫”，也稱為“無共享”。（這實際上意味著隻共享 dbms，通常是伺服器。）
從物理部署和維護的角度來看，這裡的最佳實踐是什麼？或者使用什麼準則來定義什麼時候應該是哪個選項？
由於可能性的範圍，實際上並沒有一個最佳實踐。您希望使部署和維護盡可能簡單，但您還必須考慮租戶共享的內容。
獨立的私有數據庫使某些類型的維護變得容易，而使其他類型的維護變得困難。例如，當租戶隻共享伺服器和 dbms 時，
- 為單個租戶添加自定義列、表和視圖很容易，但是
- 為所有租戶添加相同的列或表相對困難。
當租戶共享桌子時
- 為單個租戶添加自定義列、表和視圖很困難，但是
- 為所有租戶添加相同的列或表很容易。
還有其他問題。使用“無共享”進行災難恢復比使用共享表（也稱為“共享所有內容”）要容易得多。使用“無共享”，您可以只恢復數據庫。使用“共享所有內容”，您只需恢復每個表中的幾行。 當您擴大規模時，硬體成本可能是一個問題。 “不共享”更容易實現數據隔離和安全，而“共享一切”則更難。