12

對於相對簡單的數據庫需求來說,多態關係(PA)非常滿意:讓各種表在一個共享表中有子記錄。典型的例子是一張帶有評論記錄的單表,適用於不同的不一定相親的實體。如何在現有數據庫中實現多態關聯

this question馬克做了一個很好的工作,展示了三種常見的PA實現方法。我想要使​​用基表的方法,在同樣出色的answer by Bill Karwin中有更詳細的描述。

的具體例子將如下所示:

enter image description here

實體的主鍵指的是相同的密鑰值在基地臺和評論表指的是基臺,所以參照完整性被觀察到。這裏的關鍵部分是實體表的主鍵具有不同的域。它們是通過在基表中創建新記錄並將其生成的密鑰複製到實體的主鍵來生成的。

現在我的問題:如果我想在現有數據庫中引入具有參照完整性的PA的實體,它們會生成自己的相互重疊的主鍵,那該怎麼辦?

到目前爲止,我看到兩個選項:

選項1:

Option 1

每個實體保留自己的主鍵,但也得到一個備用鑰匙。

像:

  • 關閉到推薦的方法。
  • 基表穩定。

不喜歡:

  • 現有的實體必須進行修改。
  • 很難找到評論的擁有實體。

選項2:

Option 2

每個實體都有基本表自己的外鍵列。這看起來像Mark的多列方法。

像:

  • 現有實體不受影響。
  • 容易找到評論的擁有實體。

不喜歡:

  • 稀疏列
  • 基表不能穩定下來:需要時推出了具有PA新的實體修改

我瘦到選項1,可能與現場基表中的「EntityName」用於雙向查找。 哪個選項會更好。或者是另一種更好的方法?

+0

選項1會更容易維護。如果你必須不斷添加列到你的基表中,它會變得很麻煩,並且由於頁面拆分和指針等原因而需要大量的維護。 – JNK 2012-01-17 14:05:58

+0

@JNK好的一點是,物理存儲的影響很重要。 – 2012-01-17 14:43:12

+0

您可以使用選項1,但不能使用額外的替代密鑰。新的備用密鑰可以是每個實體的現有主密鑰,用一個「EntityType」列(例如'CHAR(1)'擴展,事件可以是'E',人員''P',對於產品) – 2012-02-21 13:47:16

回答

9

您可以使用選項1,但不需要額外的替代密鑰。

相反,擴展現有的主鍵(每個實體),與EntityType列(比如CHAR(1),這將是E事件,P起訴,D的產品)。

化合物(EntityId, EntityType)將成爲表Entity的主鍵和其他3個亞型表中的相應化合物。

(該EntityType僅僅是一個輔助的,參考表,以3行):

Polymorphic_Associations

相關問題