我正在重構一個可怕的交織數據庫模式，這並不是說它過於標準化;隨着時間的推移變得越來越醜陋，並且沒有非常好地佈置。數據庫模式 - 按對象或數據組織？
有幾個表（論壇板，論壇帖子，帖子的想法，博客條目）共享幾乎相同的數據結構和組成，而是因爲他們代表了從應用的角度不同的「對象」是簡單地分隔。我最初的反應是將具有相同數據結構的所有內容放入同一個表中，並在執行選擇時使用「類型」列來區分數據。
我是不是自己設置爲最高下降採用這種「全合一」的做法，並允許（潛在的）訪問相同的表中的應用程序的許多地方？僅供參考，我不能看到這個數據庫在未來一年左右增長到超過〜20MB更多...
我以前不喜歡這個「全合一」的做法，但我是被迫後使用它在幾年前的複雜項目，我成了粉絲。如果您正確地爲表格編制索引，性能應該可以。例如，您需要類型列上的索引來加速按類型操作進行排序。
現在我通常建議你使用一個表來存儲相似的對象。唯一的問題是，是否要使用子表來存儲特定於特定類型對象的數據？這個問題的答案實際上取決於每種對象類型的結構有多不同，以及您將擁有多少種對象類型。如果您有50種對象類型的結構差異很大，則可能需要考慮在主表中存儲一致的對象部分，併爲每個對象類型創建一個子表。
在你的榜樣，但是，我想你會被罰款只是把所有到一個單一的表。
欲瞭解更多信息，請看這裏：http://www.agiledata.org/essays/mappingObjects.html
有三種基本的方法來存儲對象繼承層次在關係數據庫中。每個人都有自己的優點和缺點。請參閱：
The book是偉大的。幸運的是，第3章 - 「映射到關係數據庫」 - is available freely as a sample chapter。你可以閱讀更多關於那裏的權衡。
不要倚靠太多的「應用角度來看」，它往往隨着時間的推移安韋變化。通常，數據庫也可以通過不同的應用程序訪問，並且它通常都會使它們全部活躍...
當simliar對象存儲在不同的表中時，原因可能是它們實際上代表相同的域對象，但處於不同的狀態，或在工作流程的另一個步驟中。然後將它們放在一個表中並添加一些簡單的屬性來標記狀態通常是有意義的。如果工作流程或其他任何變化，也更容易更改數據庫和應用程序，您可能不需要添加更多的表或類。