EF代碼優先：具有多個多對一關係的實體類型

考慮3類：Person,Company和File。EF代碼優先：具有多個多對一關係的實體類型

Person和Company是完全不同且無關的，但它們每個都有一個File對象的集合。無論它屬於哪個實體，File總是具有相同的結構。

這個問題是關於如何最好地模擬File可以具有的多對多關係;在這種情況下，File可以與Person或Company（但不在同一實例中）具有多對一的關係。

方法1：

class Person 
{ 
    public int Id {get;set;} 
    public ICollection<File> Files {get;set;} 
} 
class Company 
{ 
    public int Id {get;set;} 
    public ICollection<File> Files {get;set;} 
} 
class File 
{ 
    public int Id {get;set;} 
    public string Path {get;set;} 
} 

/* 
    EF Generates: 
    ----------------- 
    Table: Person (Id) 
    Table: Company (Id) 
    Table: File (Id, Path, Person_Id, Company_Id) 
*/

這似乎是最簡單的，並從代碼最簡單的第一視角，這是我最喜歡的。問題是表File，它具有Person_Id和Company_Id的無效字段。從數據庫設計的角度來看，這看起來是錯誤的，考慮到兩個字段中只有一個字段會有值，而另一個永遠是空的。使用文件集合添加更多類會更加激化問題。

方法2：

class Person 
{ 
    public int Id {get;set;} 
    public ICollection<PersonFile> Files {get;set;} 
} 
class Company 
{ 
    public int Id {get;set;} 
    public ICollection<CompanyFile> Files {get;set;} 
} 
class File 
{ 
    public int Id {get;set;} 
    public string Path {get;set;} 
} 
class PersonFile 
{ 
    public Person Person {get;set;} 
    public File File {get;set;} 
} 
class CompanyFile 
{ 
    public Company Company {get;set;} 
    public File File {get;set;} 
} 

/* 
    EF Generates: 
    ------------------ 
    Table: Person (Id) 
    Table: Company (Id) 
    Table: File (Id, Path) 
    Table: PersonFile (Person_Id, File_Id) 
    Table: CompanyFile (Company_Id, File_Id) 
*/

這樣可以完成同樣的事情方法1，並且是接近我已經在第一DB傳統設計完成。但它需要兩個額外的類，我真的不需要......或者我呢？我想這是這個問題的點...

當設計守則第一實體框架應用程序，做我需要擔心的數據庫模式？在方法1中，我可以優先考慮數據庫設計的代碼/模型簡化嗎？還是應該像方法2一樣，在腦海中編寫數據庫設計類？

來源

2016-03-14 Mark Miller

是你必須要擔心的數據庫架構，

也許沒有具體的例子，但使用繼承時尤其如此。

原因是因爲關係數據庫（特別是SQL）不知道繼承的概念。在設計你的時間表時，你必須決定哪種方法適合你的需求。

例如，創建一個學校數據庫時，你可能會設計的人，誰都有一個名稱，地址，電話號碼等

你會發現，學生和老師有姓名，地址等等。與流行的觀點相反，你會發現學生和老師都是人。

最常用的三種繼承方法。

TPH每一個分層表：一個大表的所有派生類的人，在一個表
TPT表每種類型教師的所有屬性和學生：教師/學生/人在單獨的表格中。教師和學生對他們的個人資料有一個外鍵
TPC每個具體類的表：包含教師和個人屬性的所有數據的教師表和包含學生和個人屬性的所有數據的學生表。

無論你使用哪一個取決於共享屬性的比例以及學生和教師之間的差異。如果他們幾乎擁有所有的屬性，那麼帶有一張桌子的TPH就足夠了。

但是，如果有很多教師不具備的學生屬性，那麼該表對教師而言將會有很多空值。如果與學生人數相比，教師不多，這可能不成問題，否則浪費空間可能是一個需要考慮的問題。

要考慮的另一件事是該計劃將多久改變一次。如果你真的確定教師永遠是人，而且學生和教師之間的共同屬性（=個人屬性）將永遠是常見的，那麼TPH可能會更好：三個表格：人員/教師/學生。另一方面，如果你認爲每當你需要一個學生時，你總是需要他的人物數據，那麼TPH總是會導致一個加入。也許在這種情況下，TPC可能是更好的選擇。然而，如果你經常只需要學生的特定數據而沒有他的個人數據，TPC可能不是一個好選擇

如果你不關心這個計劃，你會發現實體框架會選擇TPH：一個大的所有學生和老師均擁有學生和老師的所有特性。

如果你不想要這個，你必須告訴EF你想要其他方法之一。這是很容易使用流利的API

如何做到這一點是相當不錯的Inheritance Strategy in Code-First

描述順便說做的，完整的文章是非常有益的，我開始使用EF編程 - 代碼第一

來源

2016-03-14 10:55:39

謝謝！響應和鏈接都非常有幫助！ –

EF代碼優先：具有多個多對一關係的實體類型

回答

相關問題