單個表與多個表的特定數據庫設計方法的優缺點
我剛剛得到了一個新項目（在 JAVA 中），我正在考慮特定 DB 設計方法的所有優點和缺點。一些指示：
- 我們的應用程序有許多“內容”實體，如新聞、部落格、CMS 頁面、Wiki、建議等。我覺得這些實體中的大多數都是相似的（具有 75% 相同的欄位）但 25% 是不同的。例如，部落格可能有一些新聞沒有的額外列。
- 由於每個實體看起來“相似”，我正在考慮將它們保存在同一個數據庫表中，所有列都覆蓋每個實體。
- 數據載入：客戶可能有 100K 新聞、50K 部落格、10K CMS 頁面、100K wiki 和 50K 建議。這是客戶可能給予我們產品的最高端（最大值）。一些客戶的數據庫中可能只有 2K-5K 每種類型的項目。低端數據負載：DB中每種類型1K項。
- 此應用程序中的“讀取”比“插入”更多（客戶使用）。
我的問題：
- 將所有這些數據放在一個表中會不會對性能造成太大影響？請注意，我們將使用 Lucene 進行搜尋。
- 擁有一個包含指定實體類型的實體類型列的單個內容表，我們可以有一個處理這些實體的業務層。這將大大減少程式碼庫。這種方法有什麼缺點嗎？
請注意，我假設 C#（因為這種語言存在於標籤中）和實體框架。
兩種方法都假設實體類型是從抽象的、非持久的基礎實體類型繼承的，它累積了 75% 的欄位，因此程式碼庫討論不相關。
Table-Per-Hierarchy 的優點（所有後代都儲存在單個表中）：
- 數據庫結構更簡單（只有一張表）
- 查詢更簡單（使用 Table-Per-Type 你需要
joins 來選擇後代的行）- 審核更簡單
Table-Per-Hierarchy 的缺點：
- 該表具有低密度數據（許多可為空的欄位，根據行類型填充）。這不是問題，當有 5-6 個這樣的欄位時，但是如果有 20-25 個呢？
- 表關係和索引結構不明顯。由於您的實體將與其他實體有關係，這將導致您陷入外鍵瘋狂。想像一下你的表的外鍵。
- 數據庫結構不明顯。誰能猜到，新聞儲存在 CMS 頁面旁邊？
- 通常，90% 的實體類型都有一個
Id和Name類似的欄位（Title,Header等）。您要使用單個表儲存所有這些嗎？- 表大小會增長得非常快。隨著時間的推移，一些操作（例如，刪除）會變慢。
恕我直言，每個映射到關係數據庫的繼承方案都應該非常小心地使用。絕對不應該將所有實體映射到單個表。
當我在大學學習系統分析模組時，我正在攻讀電腦科學學位。我們的講座當時告訴我們的一件事是我們無法理解的。
"Strictly speaking, there is no wrong or right way to approach DBs"作為電腦科學家，這很難接受。
讓我們看看你的例子：
好的，所以你有相似的實體。它們僅在“類型”上有所不同。所以你的想法是使用一個表，然後使用這個“類型”欄位來區分。部落格可能擁有的任何額外列在其他列中都將簡單地為空。
**優點？**易於管理，易於查詢，刪除重複欄位，您可以說這是正確的方法。
**缺點？**欄位增長很大（混亂），表大小很大，許多可以為空的單元格，多訪問很有可能導致更新表出現問題。所以，在某種程度上，你的方式也是錯誤的。
所以採取基本的評估沒有錯誤的方法，在大多數程序員喜歡的理性思維中沒有正確的方法。不幸的是，如果它適合您的需求，這是正確的。
你需要考慮影響。好的，我獲得了超級簡單的查詢，如果我做一些報告，這對我很有幫助，很棒的東西。如果這個網站的流量很大怎麼辦？你會遇到一個擁有一個“超級”數據表的問題。
我接近 DB 的最佳方法是違背程式碼第一種方法試圖做的目前時尚。首先停止認為您可以將程式概念扔給它。根據推理，重複數據很好。（請注意，如果您堅持良好的原則並正確使用規範化，這實際上很少發生，但是如果它適合您的需要，您仍然可以這樣做）
開始規範化你的實體，你已經知道它們是什麼，開始分解它們，同時保持佈局的記錄（通常是排序圖最好）。一旦你有了這些基礎實體，就開始進一步規範化這些實體的過程，請注意不要過度規範化。
雖然從程式碼的角度來看，這似乎需要做很多工作，但您需要生成一些複雜的查詢。這就是衝突，數據應該是可獲取的，應該使用它，看看預期的流量來推動你的數據庫設計，一般概念是高流量=更多規範化，低流量=更少。
最後，對於您的問題，它會損害性能嗎？是的，但是表索引與關係連接的成本（假設關係數據庫設計）本身就是一個需要研究的整體問題。當您獲得簡單的查詢和更少的程式碼時，性能差異並沒有任何人期望您會感到驚訝的不同，但是真正的問題是鎖，即使有適當的索引，也會發生巨大的鎖，當這種情況開始發生時你會看到巨大的性能損失和煩人的日誌！
是的，您的程式碼會減少，但對您的數據庫的壓力會增加，如果性能不存在並且出現問題，那麼沒有什麼能阻止您這樣做。
**我的想法？**再次讓我強調這都是基於意見的，確實沒有錯誤或正確的方法，您的模型涉及很多因素。但是，我會將您的實體拆分，創建圖表以顯示佈局。
希望這沒有讓您感到困惑，DB 是一個有趣的東西，其中 1 和 0，真假並不真正適用於方法。一般來說，雖然我喜歡考慮兩件事，性能與可維護性。