關於具有共同屬性的SQL表

Question

我在想一個問題，並且總是在我們的日常開發生活中發生。 例如，我有一個table1 20列，table2 30列，表3 40列。但對於表1,2,3，他們有共同的10列。

有幾個例子可能會把它放在上下文中。

寵物商店大約有狗，貓，金魚等，所有的寵物有一個名稱，價格，得到的日期等，但每種寵物都有屬性，其他類型的沒有數據。

約車輛數據庫具有關於汽車，卡車（貨車），和摩托車的數據。他們都有車輛識別號碼，註冊號碼和製造年份。但他們每個人都有自己的屬性。

有關客戶數據庫有關於公司的那些客戶，和個人是客戶的數據。他們都有電話號碼，但他們也有不同的屬性。

那麼什麼是DB結構的合理設計。 A：用20,30,40列創建3個表格？ B：創建3表10,20,30列和另一個表共10列？如果我搜索一個記錄，我需要加入共同表

因此我該如何分析這個性能題？不知道sql的工作原理，會爲此做一些調查工作。 任何人都可以共享有關設計和不同的性能

Answer 1

這種問題表面一遍又一遍在數據建模你的想法。它在ER建模中被稱爲「泛化/專業化」，在對象建模中被稱爲「超類/子類」。

對象建模器使用內置的對象模型的繼承功能，很容易解決的問題。子類只是擴展超類。 關係建模者面臨一個問題。如何設計表格以模仿從繼承中獲得的好處？這是你提出的問題。

最簡單的技術稱爲單表繼承。有關所有子類的數據被分組到一個超類的單個表中。有一個列object_type將所有單個類型的對象組合在一起。沒有任何對象可以屬於多種類型。如果某列與其中一個子類無關，則該列在與該子類相關的行中將保留爲NULL。

這種簡單的解決方案非常適用於較小的和簡單的情況。存在大量的NULL會增加存儲開銷的一小部分，並且檢索開銷稍微增加一點。如果布爾測試在可空列上完成，開發人員可能必須學習SQL三值邏輯。起初這可能會讓人困惑，但人們已經習慣了。

還有另一種叫做類表繼承的技巧。在這個設計中，除了所有專用子表的組合表之外，還有每個專用子類的獨立表。當你需要關於特定類型對象的所有數據時，可以使用適當的專用表來加入常規表。在這個設計中有更少的NULL，但你做更多的加入。這種技術在更大和更復雜的情況下效果更好。

還有第三種技術稱爲共享主鍵。這種技術通常與類表繼承一起使用。子類的專用表具有作爲其主鍵的普通表中相應條目的主鍵的副本。此id列可以聲明爲主鍵和外鍵。

這需要在添加新對象時進行一些額外的編程，但它會使連接變得簡單，輕鬆和快速。

超類和子類在現實世界中一直髮生。讓你的設計簡單而健全。測試你的初始設計的性能。然後調整它，如果你需要。