多個數據庫，更少的表？一個數據庫，很多表？

Question

我最近從事IT方面的工作，雖然我的專長是應用程序設計，但我一直負責修復和更新他們當前的數據庫結構和應用程序。

他們當前的數據庫包含20個相互關聯的數據庫，與數百名在數百個不同的意見（無存儲過程）。一切都與一系列訪問前端相關聯。

現在服務器架構是非常奇怪的，對面有含有相同或接近相同數據的數據庫一噸重複的表，所以很明顯這在很大程度上可以被合併了。然而，以前的開發奠定了應用程序的方式是讓每一個單一的應用程序單獨的數據庫，一個名爲「Shared_Tables」另一個數據庫包含一些的需要表之間傳遞信息。

現在我的主要問題是，因爲我基本上是從頭開始爲公司創建一個新的系統結構，是否有使用分離數據庫的任何真正的優勢，或者將它們合併到一個數據庫中一樣有效，假設他們都在同一個實例上運行？值得注意的是，沒有一個數據庫具有主鍵，唯一鍵，外鍵等等。而且，當它們應該相同時，跨多個字段的數據類型會有所不同。

Answer 1

我同意@院長的職務。另外推薦立即破解數據庫結構的帖子是一個壞主意。如果數據庫數量很多，並且提供了大量的表格，那麼您會導致更多問題而不是解決它們（性能和迴歸錯誤是一個大問題）。

我提出以下建議：

1. 做你的分析，對公司的數據庫的當前狀態（貌似你已經做到了這一點）。確切地指出問題出在哪裏，然後用他們理解的行話轉達給你的經理。也就是說，這些是問題清單，需要多年的時間才能修復當前的系統等。
2. 確定當前和未來的要求。這家公司在哪裏與他們的IT系統，他們的數據要求是在每種情況下。然後研究當前結構是否可以處理/支持他們當前/未來的需求。如果不是，再次指出支持證據爲什麼不能這樣做。再次用一種他們能夠理解的術語來傳達給管理人員。

上述（1）和（2）的要點是什麼？重要的一點是，如果您沒有IT系統的背景知識，並且有信心開始黑客入侵，特別是像您提到的那樣合併表格，那麼參與這個項目非常困難。你需要說服你的管理者，最好的選擇是重新開始，爲此你需要具體的證據來支持你的建議（我假設你寧願從頭開始設計，而不是破解當前的數據庫結構）。

這將是更好的從一張白紙開始，設計你看到系統擬合根據當前和未來的需求。您仍然需要分析現有的結構，但是您只需要爲新的數據庫設計提供所需的內容。祝你好運，我希望它有幫助！

Answer 2

恐怕你從錯誤的一端接近的問題。

如果您有從頭開始重新設計的奢侈品，請從邏輯數據設計開始。將數據庫視爲正確性的單位（所有約束都包含數據庫，並且所有約束都應該爲真）。證明你的實體和它們之間的關係。識別密鑰。扣除並正常化。只有在這之後，你才應該關注性能和效率。並不是說你不會爲了獲得更好的性能而改變一些漂亮的設計，只是應該始終從可靠的數據模型開始。

的回答「有多少數據庫」的問題自然會從那裏跟隨。