2011-03-29 124 views
0

我相信我不是第一個提出這個問題的人,但我找不到一個好的答案,我承認數據庫設計不是我的主要優勢。數據庫設計:在超類型/子類型上加入表

假設我有一個產品,並且此產品可以有子類型,產品A,產品B,產品C和產品D.超類型產品將具有一些共同屬性,而子類型將具有特定於這些子類型的屬性。相當標準的超類型/子類型設計。

現在我有一個用戶實體。產品可以有許多用戶,並且用戶可以有許多產品。所以理想情況下,我想在這些連接表上加上一些關於該連接的特定屬性。我遇到的問題是我不想做Product-User連接表,但更像是與User和Product子類型的連接,因此是ProductA-User,ProductB-User,ProductC-User,ProductD-User。原因是這兩個實體的連接具有特定於該產品和用戶連接的自己的屬性。

這個設計是否有意義?還是有更好的方式來處理這種行爲。我喜歡我的產品的標準超類型/子類型,但當我需要將它們與其他實體結合時,我不確定如何處理。

回答

2

在某些數據庫中加入超類型是有意義的,在某些數據庫中加入各個子類型是有意義的,並且在某些數據庫中將不同數據加入到超類型和子類型中是有意義的。

真的是(ProductA,User)的表有不同的列(ProductB,User)嗎?如果是這樣,那麼你的答案。不同的屬性,不同的東西,不同的表格。將m:n表分開,並引用子類型。

(後來)

我回答another SO question並列入該做的正是這種代碼。

+0

我看了一下你的例子,謝謝你指出了一個例子。這種情況下,與用戶連接時的子類型會有不同的列。 ProductAUser和ProductBUser將具有不同的列。 – 2011-03-31 14:55:21

0

好吧,如果你想捕獲有關ProductA-User關係和ProductB-User關係的不同信息,那麼Product-User表似乎沒有意義。就個人而言,當我有產品表,以及ProductA,ProductB等時,我對此表示遺憾,無論是出於性能還是可維護性原因。我的直覺反應通常是消除產品表。

+0

我普遍贊同這一點。其他一些要考慮的事項是某些數據庫上的稀疏列,其中空列佔用較少的空間。此外,如果您需要查詢一個位置,則可以在ProductA,ProductB表的聯合體上創建視圖。 – squawknull 2011-03-29 01:27:24

+0

因此,對於這條路線,您是說真的沒有理由使用超類型/子類型設計,並且只有ProductA,ProductB等表以及與用戶的單獨連接表?這可能會有一些冗餘的數據,但如果稍後它會變得不那麼麻煩,那麼這可能是更好的選擇。 – 2011-03-29 02:23:00