2009-07-13 104 views
3

注意:我無意實現這一點,它更像是一個思想實驗。單獨數據庫中的用戶表

假設我有多個可通過Web界面訪問的服務。其中至少有兩個需要用戶註冊和數據庫中的一些數據。單一註冊將授予對所有服務的訪問權限。像谷歌(GMail,谷歌文檔等)。

所有這些與註冊用戶相關的服務是否都位於單個數據庫中,可能使用表前綴來表示它們的服務?

或者每個服務都有自己的數據庫嗎?我唯一可以看到的是,它可以使表名更清晰。任何時候都需要用戶交互,至少需要與兩個不同的數據庫進行交互,這將不必要地使sql查詢複雜化。

這是否表明'大男孩'只使用一個數據庫,並加載了大量不同的(也許完全不相關的)表?

+0

到目前爲止,我們都很喜歡這些答案,因爲它們遵循我當時的想法,但與我期待聽到的相反。 – nilamo 2009-07-13 21:47:39

回答

3

如果您使用正確的DBMS,您可以擁有兩種策略中最好的一種。在PostgreSQL中,在「數據庫」中可以有單獨的模式。身份驗證服務將訪問單個模式併爲其他服務提供一個用作其他模式中的數據引用的密鑰。您仍然可以處理整個數據庫作爲一個單一的實體,即:

  • 跨模式的查詢,而無需單獨使用DBLINK
  • 儲存個人身份信息(的模式可以有單獨的每個用戶的權限,以進一步保護數據)
  • DBMS管理的外鍵約束(我相信)
  • 一致(重數據)備份和恢復

您一個更復雜的DAL的成本獲得這些優勢(您最喜歡的DAL框架可能不支持)以及DBMS之間的可移植性較差。

+0

聽起來很酷。我所有的經歷都發生在SQL Server和/或MySQL上,所以我必須深入研究這一點。 – nilamo 2009-07-13 22:16:12

3

我不認爲這是一個好主意,使多個服務依賴於單個數據庫。如果您需要從備份中恢復某項服務,則必須全部恢復。 您可能也正在重載數據庫服務器。 只有在未來可能他們會共享大量數據的情況下,我纔會這樣做。

此外,你可能會考慮只有共享用戶數據的小型數據庫。

+1

在這種情況下恢復數據時保持一致是另一個挑戰。 – 2009-07-13 22:04:26

3

我會考慮有一個用戶/角色存儲庫與服務的單獨數據庫。

1

潛在的超載數據庫及其訪問一直存在問題;複製是一個很好的解決方案。

2

我從來沒有這樣做過,但我認爲這取決於性能。如果分開的數據庫幾乎沒有開銷,那可能就是答案。做單獨的數據庫也可以很容易地跨計算機分割數據庫。

複雜性也是一個問題。希望您的模式可以這樣定義,即不需要爲不同的查詢而插入幾個不同的數據庫。

1

有幾種策略。

當您移動到多個數據庫(或多個服務器)時,事情變得更加複雜。您的核心用戶信息可能位於單個數據庫中。個別服務可能在其他數據庫中。問題在於數據庫是參照完整性的外部單位,因此您不能在跨數據庫的外鍵中進行設計。解決這個問題的方法之一是將更改分發給核心主表(顯然,只會增加和更新,因爲刪除會因外鍵約束而被禁止)定期分離數據庫,然後對這些副本強制實施RI服務數據庫中的核心主數據庫表。這也意味着服務數據庫及其服務可以在其他數據庫停機維護時運行。顯然,這是一個增加的架構複雜性,可以改善您的服務窗口並減少耦合。

我建議從單個數據庫開始。如果你的RDBMS支持它,我會根據SCHEMAs來組織組件,這將允許你至少保持設計的邏輯分離。您稍後可以更輕鬆地進行重構。

許多數據庫都有可能被視爲無關的表。有時在一個系統中,你有多個實體網絡幾乎不能連接(有時根本就沒有)。您也可以在這些情況下使用SCHEMAs。

相關問題