如何知道何時爲非常相似的對象類型創建新表格？你怎麼知道你什麼時候需要單獨的表格？
例如：
學習mysql我正在構建一個模型太陽系。就我的項目而言，行星與矮行星，半人馬和彗星有許多相似的屬性。矮行星幾乎與行星完全相同。半人馬和彗星只有不同於行星，因爲它們的軌道有更多的變化。我應該爲每種類型的對象都有一個單獨的表，還是應該共享表？
這個例子可能太簡單了，但我也對最佳實踐感興趣。就像我應該使用單獨的表格，以防萬一我想在未來使行星和矮行星變得不同，或者它們是將它們保持在同一個表中的任何效率原因。
Normal forms是你應該感興趣的。他們幾乎是建立表格的慣例。
任何不會破壞first，second或third正常形式的設計對我來說都很好。這是一個相當長的需求清單，所以我建議你去閱讀上面的維基百科鏈接。
這就是所謂的Database Normalization
有很多正常的形式。通過應用規範化，您將會瀏覽元數據（表格）並更清楚地研究數據之間的關係。通過使用規範化技術，您將優化表以防止冗餘。此過程將幫助您瞭解根據不同字段之間的關係創建的實體。
如果您想要在單個查詢中獲取行星和彗星，那麼如果您希望數據庫能夠高效工作，它們幾乎必須位於同一個表中。繼承應該在你的應用程序本身內部進行處理:)
這取決於你想要存儲的關於對象的信息類型。如果所有這些信息都是相同的，比如說軌道半徑，質量和名稱，那麼你可以使用同一張表。然而，如果每個屬性都有不同的屬性（比如說行星等的大氣成分），那麼你可以爲每個屬性（不是非常規化的）使用單獨的表格，或者爲軌道，質量和名稱等基本屬性使用一個表格，第二個表格只是行星所特有的屬性（如果需要的話還有類似彗星的表格等）。所有對象都在第一個表中，但只有行星會在第二個表中，並通過外鍵鏈接到第一個表。
你應該最有可能拆分有關行星的數據等，以便共享（公用）信息在另一個表中。
E.g.
Common (Table)
Diameter (Column)
Mass (Column)
Planet
Population
Comet
Speed
我認識的柱子很差。 Planet和Comet表格通過一個鍵鏈接到Common數據。
這絕對是一個主觀問題。這聽起來像你已經在正確的思路上。我會問：
你也可以問問自己，你將如何來查詢數據。你會想要把他們都放在同一個列表中嗎？將數據與其他通常被查詢的數據結合到表中總是一個好主意。例如，如果您通常想要查詢所有附件，則可以使用「附件」表格，其中的文件可以是圖片或視頻，而不是圖片和視頻表格。除非有很好的理由，否則不要拆分爲多個表格。
這裏是我的回答類似的問題，我想在這裏也適用：
有許多不同的方式來表達你的關係模型繼承。例如，您可以嘗試將所有內容壓縮到一個表中，並且有一個允許區分不同類型的字段，或者具有一個共享屬性表以及具有特定屬性等的子表的關係。你仍然存儲相同的信息。從領域模型走向關係模型時，這就是所謂的阻抗失配。兩種選擇都有不同的折衷，例如一張表可以更容易查詢，但多張表的數據密度更高。
根據我的經驗，最好不要嘗試回答從數據庫的角度來看這些問題，但讓你的域模型，並選擇有時候你的應用程序框架，推動表結構。當然，這並不總是一個可行的選擇，特別是在表演方面。
我建議你先在紙上畫出你要表達的關係，然後從那裏開始。你選擇的表格結構是否準確表示域名？是否可以查詢提取您想要報告的信息？你寫的查詢是複雜還是緩慢？回答這些問題以及像他們這樣的其他人將有希望引導您創建一個良好的關係模型。
我也建議對數據庫規範化閱讀，如果你是認真學習的好關係建模校長。
我可能就會有一個叫[HeavenlyBodies表或一些這樣的事情。然後有一個與身體的類型，即星球，彗星，小行星，明星等查找表。所有將共享類似的東西，如名稱，大小，重量。到目前爲止，我閱讀的大多數答案都有很好的建議。規範化是好的，但我覺得有時候你可能會做得太過分。第三次正常是一個好目標。
或創建一個空間對象表，其中包含公共信息和分類表，其中包含特定於對象類型的不同分類和說明。如果您需要進一步的分類信息，您可以爲不同的分類類型創建更多的表格。 – 2010-01-20 20:25:35