0
假設我有TPH抽象類Person
。然後我有從這個類派生的Girl
和Boy
。 Girl
與FavoriteMakeup
有關係Boy
沒有。插入Boy
記錄時,如何滿足Makeup
上的FK常量?或者TPH與FK限於派生類型不兼容?TPH - FK在派生類上時如何滿足FK constaint?
假設我有TPH抽象類Person
。然後我有從這個類派生的Girl
和Boy
。 Girl
與FavoriteMakeup
有關係Boy
沒有。插入Boy
記錄時,如何滿足Makeup
上的FK常量?或者TPH與FK限於派生類型不兼容?TPH - FK在派生類上時如何滿足FK constaint?
這裏有兩個不同的方面。讓我們來看看他們兩個。
第一種情況是外鍵在關係數據庫管理系統中的值是否爲空值。通常這是允許的:你可以同時擁有一個外鍵約束和一個非空約束或一個外鍵約束,而該屬性可以同時爲空。這是因爲兩個約束通常被認爲是獨立的。例如,NULL值可能意味着該值對於特定對象是未知的。
第二個方面是有關造型:通常情況下,像你的例子情況下,當你可以使用「表每一個分層」的方法,這是不被認爲是良好的建模方法:你應該每使用「表鍵入「(或TPT使用Microsoft文檔的術語)的方法,因爲所有的女孩實體都與其他實體化妝有關聯,而實體男孩沒有這種關聯,並且這個事實是實體的部分含義,而不是某個實體的某種特殊情況(如未知值)。
雖然由於代碼重複,但我非常害怕TPT。要麼我開始重複代碼(在模型定義中),要麼渾濁我的商業邏輯。有沒有「正確」的方式還是這種哲學? – RobVious
在數據庫世界中,實際上TPT方法在子類中使用很多,您可以在所有數據庫書籍中找到它。你是否說你在重複代碼?如果您的應用程序級別是用對象關係映射框架編寫的,那麼通常的繼承機制不會引入重要的代碼重複。 – Renzo
我的意思是,如果我們看看TPT的含義,我將有三個或四個「支付」表,每個表共享約50-70%的列定義。這似乎不如在一個地方與業務邏輯實施數據關係那麼理想......但我不知道。 – RobVious