數據庫功能分解模式？

Question

我們有以下問題。我們的企業應用程序在MySQL中有一個數據庫，看起來它的結構變得太複雜 - 超過100個表（它已經開發了7年）。

但是，大多數表與其他表完全沒有任何關係。每個人都使用一些常用的表格（字典）（大約有20個這樣的表格），但僅此而已。問題出現在如何使這個數據庫更快，更可靠。

我讀了很多關於數據庫分解的知識。也就是說，您將與不同數據庫中的不同域相關的表。例如，與運單和其他紙張相關的任何內容都放在名爲紙張的數據庫中，而與客戶及其訂單相關的任何內容均放置在名爲「客戶」等數據庫中。

在這裏，我們有兩個問題：

• 用戶應該看到企業應用程序，作用於單個域。開發人員必須以某種方式更改與數據庫一起工作的核心，以便它可以處理多個數據庫。
• 常見的表格會產生問題。它們必須保存在單個數據庫中，並且在分解後不能在所有數據庫中複製。因此，我們如何進行查詢SELECT * FROM A JOIN B，A和B在不同的數據庫中（在不同的服務器上）？

這兩個問題實際上解決了同樣的問題 - 是否有任何常見的企業模式（如GoF）來解決這個問題？我對適用於Java EE的模式特別感興趣。

Answer 1

我不一定會將表組移動到他們自己的數據庫中 - 這會使系統更加複雜，現在您還有其他問題，如同步多個數據庫的備份。 IMO 100表格根本不笨重。

但是，如果需要將系統（和數據庫）的功能分解爲多個系統的業務驅動需求，那麼一定要這樣做。顯然，這需要對系統進行重大更改甚至重寫。

回覆：運單，發票等不幸的是，MySQL並沒有像其他RDMS的MS SQL Server一樣實現Schema。 您可以通過向表格添加前綴（PaperWaybill，PaperInvoice等）來模擬模式固有的命名空間。

但是，更改表名稱現在大概不明智的考慮到你的系統已經在生產了7年，並釘了所有的依賴可能是有難度的 - 例如，可能有幾個應用程序，報告，作業等都訪問這些表。

國際海事組織你需要了解爲什麼有這麼幾個關係的核心原因。 有可能存在關係，但是，FOREIGN KEYS被丟棄，例如，爲performance reasons。如果這是阻礙來圖系統你的能力，或阻止工具，如ORM代碼生成器從創建關係，則可以將PROD數據庫還原到一個開發環境，並添加外鍵回DEV。同時，您會了解數據的質量 - 例如FK約束。