理解類表繼承

我有一個產品表中調用products 它有3個字段（名稱，型號（PK），和CLASS_NAME）。該類對應於一個表。所以這裏有一個例子：理解類表繼承

產品表：

model | name | class_Name 
z123 | Abcd | AMPS

AMPS表：

model | attribute_1 | attribute_2 
z123 | blah blah | blah blah

問：

我是否應該保存的PK表（模型）和其相應的類名稱，然後在我的產品表中使用類ID？擁有一個可以容納所有模型及其類的表格會更有效率嗎？

添加了SQL標籤，以便實際獲得答案。 – 2012-02-22 23:50:38

@DhaivatPandya謝謝！ – 2012-02-22 23:51:45

我沒有看到你在做什麼錯，我懷疑添加表會有所幫助。但是，您應該考慮詢問更具體的問題。你的目標是什麼？如果你擔心效率，你想優化什麼？ – 2012-02-23 00:10:08

這看起來像一個「子類」（aka。「category」）層次結構。如果你有和總是只有AMPS，並沒有其他「子級」，那麼你可以考慮合併它與Product。否則，它看起來不錯。

BTW，有3 ways實現在關係數據庫中的類層次，各有長處和短處。將所有類保存在一個表中是其中的一個，但可能難以維護，並且對於某些類型的參照完整性可能存在問題。你已經在使用（「每類表」）也許應該是您的默認選擇，除非有另有一個令人信服的理由，該模型...

2012-02-23 01:54:10

是的，每款產品都會有特定的類別。我知道實現類層次結構的三種方法，「每個表的類」看起來像是解決我所遇到的特定問題的最合理的方法。謝謝 – 2012-02-23 02:24:00

有已經是一個公認的答案，但我加入的好處如下的其他人在運行此Q.請注意，此解決方案與在主表中指示子類明顯不同。在我看來，它既簡單又靈活。

你的情況看起來像被稱爲「泛化專業化」（根規格的簡稱）設計模式的一個實例。 gen-spec模式對於面向對象的程序員來說很熟悉。在教授關於繼承和子類的教程時將會介紹它。

實現gen-spec模式的SQL表的設計可能有點棘手。數據庫設計教程常常掩蓋了這個主題。但它在實踐中一次又一次地出現。

如果你搜索「泛化專業化關係建模」網頁，你會發現一些有用的文章，教你如何做到這一點。在這個論壇中，你也會被指出幾次這個話題。

這些文章通常告訴你如何設計一個表來捕獲所有的通用數據和一個專門的表將包含所有特定於該子類中的數據的每個子類。有趣的部分涉及子類表的主鍵。您不會使用DBMS的自動編號功能來填充子類主鍵。相反，您將編寫應用程序以將通用表中獲得的主鍵值傳播到適當的子類表中。

這在廣義數據和專用數據之間建立了雙向關聯。每個專門的子類的簡單視圖將一起收集廣義和專門的數據。一旦你掌握了它，它很容易，它表現相當好。

2012-02-23 14:22:03

回答