映射導航屬性

Question

我有以下數據庫模式：

我使用表每次Hiearchy（TPH）的繼承。 「案例」表的「類型」字段確定案例是電子郵件案例還是嘰嘰喳喳案例。它們都是與Cases表的1：N關係。

我使用數據庫先用EF辦法，這就是我要使用的模型：

的問題是，我無法使用外鍵導航屬性映射到子表， （Email.CaseId < - > Cases.Id和Tweets.CaseId < - > Cases.Id）。我想要實現的是EmailCase實體具有導航屬性來發送電子郵件，而TwitterCase實體具有一個Tweets。

我可以使它工作，只有當我手動添加關聯，然後導航，但當然這不會反映在數據庫中。

我該如何解決這個問題？我應該使用Table-per-Type（TPT）而不是TPH嗎？但在這種情況下，例如EmailCase只會包含一個ID到原來的情況，沒有別的，這聽起來很奇怪。 （這是如果我使用模型第一種方法會產生什麼）。

或者我應該手動添加關聯和導航屬性？

Answer 1

這是很難回答，因爲有兩個明顯的好處 - 一個票TPH和其他爲TPT：

• 您模型非常適合TPH因爲所有屬性都是在基類和派生類不會爲表添加屬性。因此，三個實體的所有查詢（或兩個，如果Cases是抽象的）只需要這個表，並且不涉及任何連接 - >對性能有好處。另一方面，該數據庫將允許您的模型不一致，例如具有Emails記錄，CaseId = 1指的是Cases記錄，此Id = 1但Type鑑別符是TwitterCase。如果你只使用EF來訪問數據庫，如果EF正確地執行它的工作，這個調整不應該發生。如果您有其他來源可能會更改數據庫，可能會發生。

• TPT會解決的可能模式不一致的問題，因爲CaseId在Emails表將參照隨後的EmailCases表和CaseId在Tweets表到TwitterCases表。但價格是你有這些奇怪的表，它只包含主鍵的一個列，每個查詢 - 不管它有多簡單 - 都會涉及Cases表與派生類型的表之間的聯接 - >對於性能。

什麼對你更重要？就我個人而言，如果只有您的EF應用程序訪問數據庫，由於性能優勢，我會稍微傾向於TPH。但如果不知道應用程序的整個上下文，我不能最終決定做什麼。