0
我有以下實體:書籍,作者和商店。子類型或單獨的表?
他們每個人都可以有評論部分。我應該將註釋存儲在單獨的表格中還是具有子類型/超類型設計?如果我使用單獨的表格,這在技術上是錯誤的嗎?因爲無論哪種方式,它可能需要相同數量的工作,或者如果超類型層次結構針對任何子類型而改變,則子類型設計可能需要更多工作。
我有以下實體:書籍,作者和商店。子類型或單獨的表?
他們每個人都可以有評論部分。我應該將註釋存儲在單獨的表格中還是具有子類型/超類型設計?如果我使用單獨的表格,這在技術上是錯誤的嗎?因爲無論哪種方式,它可能需要相同數量的工作,或者如果超類型層次結構針對任何子類型而改變,則子類型設計可能需要更多工作。
超類型和子類型攻擊問題「這些東西不完全相似,但它們也沒有完全不同。」
超類型/子類型設計要求某些屬性存儲在超類型中,有些屬性存儲在子類型中。現實世界中每個事物的屬性都分爲兩個表格。
你如何決定如何分割屬性? 共有的屬性全部子類型向上移動到超類型中。所以,如果你開始的公司和個人,他們並不完全一樣,因爲
等。
他們不是完全不同,因爲
等等。
兩個共同的屬性(合法名稱,至少)會冒泡到超類型中。
不過,對於您的情況,目前還不清楚書籍,作者和商店如何適合該分析。很明顯,他們不完全一樣。但他們完全不同嗎?我想是這樣。
如果您正在討論關於書籍,人員和商店等網站帖子,那就是另外一回事了。 answer to a similar SO question包含代碼。
評論適用於書籍,作者和商店(評論的屬性在3個實體之間相同)。即使評論屬性是相同的(每個評論類型的表格等),對於每個實體都有3個單獨的評論表在技術上是錯誤的嗎?它會被視爲規範化,因爲您正在重複每個評論類型表的評論屬性? – firebird
@firebird:技術上錯誤?也許。 (但它與規範化沒有任何關係。)具有重疊含義的表違反了正交設計的原則。請參閱http://www.dbdebunk.com/page/page/622331.htm –