EF Core eins zu viele zu viele zu eins

Question

Ich habe schon lange mit Datenbanken gearbeitet, bin aber neu im Entity Framework. Ich handle sowohl mit den Aspekten der Programmierung als auch mit der Datenbankentwicklung. Als db-Entwickler versuche ich, es sauber zu halten, daher funktioniert diese Struktur gut für mich, aber ich bin mir nicht sicher, ob Entity Framework es sogar unterstützt, da ich es seit mehreren Tagen mit verschiedenen Szenarien, Datenanmerkungen, versucht habe wie auch Fluent API, aber das konnte nicht funktionieren.

Was ich versuche, könnte ein bisschen unkonventionell sein, aber was ich vermeiden möchte, ist eine Dateitabelle für jeden Bereich zu duplizieren, daher definiere ich 1 Dateitabelle, die von mehreren Bereichen mit einer Beziehung verwendet werden kann . Also, was ich habe ist: eine [Firma, Mitarbeiter oder Projekt] kann viele Dateien haben (eins zu viele). In ähnlicher Weise kann die Dateitabelle von jedem Bereich bezogen werden (viele zu viele, in diesem Fall sind es nicht die Daten, sondern eher die Struktur, die hoffentlich sinnvoll ist). Die Dateidatensätze beziehen sich nur auf einen Bereich [Firma, Mitarbeiter oder Projekt] (viele zu eins).

Der offensichtliche Vorteil dieser Methode ist, dass ich vermeiden kann, 3 Datei-Tabellen zu verwalten, aber es endet nicht dort. Wie Sie aus der FileAccess-Tabelle sehen können, muss ich, anstatt mehrere Tabellen hier zu haben oder mehrere Felder, um Zeiger auf die mehreren Tabellen darzustellen, nur eine Tabelle für den Dateizugriff verwalten. Der Schlüssel befindet sich in RelationTable und RelationId und nicht in der spezifischen File.Id.

Unten ist ein vereinfachtes Beispiel der Struktur, die ich versuche zu erreichen. Kann es im Entity Framework gemacht werden?

public class Company 
    { 
    public Guid Id { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<File> Files { get; set; } 
    } 

    public class Employee 
    { 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<File> Files { get; set; } 
    } 

    public class Project 
    { 
    public int Id { get; set; } 
    public Guid? CompanyId { get; set; } 
    public string ProjectNo {get; set; } 
    public virtual ICollection<File> Files { get; set; } 
    } 

    public class File 
    { 
    public int Id { get; set; } 
    public Int16 RelationTable { get; set; } 0=Company, 1=Employee, 2=Project 
    public string RelationId { get; set; } Company.Id, Employee.Id, Project.Id 
    public string FileName { get; set; } 
    } 

    public class FileAccess 
    { 
    public int Id { get; set; } 
    public int EmployeeId { get; set; } 
    public Int16 RelationTable { get; set; } 0=Company, 1=Employee, 2=Project 
    public string RelationId { get; set; } Company.Id, Employee.Id, Project.Id 
    public string AccessType 
    } 

Answer 1

Als Ivan wies darauf hin, hat EF dies nicht aufgrund der Fremdschlüssel Einschränkungen unterstützen, aber ich war in der Lage mit einer Arbeitslösung zu kommen. Allerdings muss ich Sie warnen, dass ich erst in der 3. Woche von EF bin, also weiß ich nicht, welche Auswirkungen dies verursachen kann, aber das ist, was ich getan habe, für diejenigen, die interessiert sein könnten.

Wie sich herausstellt (durch Versuch und Irrtum), EF muss nur die OnModelCreating die Beziehung zwischen den Objekten verkabeln, ist es nicht wirklich brauchen die FK damit geschaffen werden ich die Beziehung auf diese Weise definiert:

Wenn Sie die obigen Codes hinzufügen und die Add-Migration ausführen, werden die folgenden Codes hinzugefügt, wodurch der Update-Database-Befehl aufgehoben wird, sodass Sie ihn in der Up-Funktion auskommentieren müssen .

 //migrationBuilder.AddForeignKey(
     // name: "FK_Files_Projects_RelationTable_RelationId", 
     // table: "Files", 
     // columns: new[] { "RelationTable", "RelationId" }, 
     // principalTable: "Projects", 
     // principalColumns: new[] { "RelationTable", "Id" }, 
     // onDelete: ReferentialAction.Cascade); 

     //migrationBuilder.AddForeignKey(
     // name: "FK_Files_FileAccess_RelationTable_RelationId", 
     // table: "Files", 
     // columns: new[] { "RelationTable", "RelationId" }, 
     // principalTable: "FileAccess", 
     // principalColumns: new[] { "RelationTable", "RelationId" }, 
     // onDelete: ReferentialAction.Cascade); 

Sie müssen das gleiche mit der Down-Funktion tun, sonst wird nicht Sie in der Lage sein, um die Änderungen rückgängig zu machen.

 //migrationBuilder.DropForeignKey(
     // name: "FK_Files_Projects_RelationTable_RelationId", 
     // table: "Files"); 

     //migrationBuilder.DropForeignKey(
     // name: "FK_Files_FileAccess_RelationTable_RelationId", 
     // table: "Files"); 

Jetzt können Sie eine Update-Datenbank machen und es sollte gut laufen. Das Ausführen der App funktioniert auch einwandfrei. Ich kann die EF-Methode verwenden, um das Projekt mit den zugehörigen Dateien abzurufen, und mit dem FileAccess-Objekt arbeiten. Beachten Sie jedoch, dass dies ein Hack ist und zukünftige Versionen von EF dies möglicherweise nicht unterstützen. Prost!