EF 코드 - 처음으로 불필요한 외래 키 열을 생성하는 이유는 무엇입니까?

Question

나는 자동으로 내 데이터베이스 스키마를 작성하는 엔티티 프레임 워크 코드를 먼저 사용하고

, 나의 실체 중 하나는 다음과 같습니다

public class AssessmentsCaseStudies { 
    #region Persisted fields 
    [Required] 
    [Key, Column(Order=0)] 
    [ForeignKey("Assessment")] 
    public int AssessmentId { get; set; } 

    [Required] 
    [Key, Column(Order=1)] 
    [ForeignKey("CaseStudy")] 
    public int CaseStudyId { get; set; } 

    [Required] 
    public int Score { get; set; } 

    [ForeignKey("Follows")] 
    public int? FollowsCaseStudyId { get; set; } 
    #endregion 

    #region Navigation properties 
    public virtual Assessment Assessment { get; set; } 
    public virtual CaseStudy CaseStudy { get; set; } 
    public virtual CaseStudy Follows { get; set; } 
    #endregion 
} 

EF 내 데이터베이스를 자동 생성 할 때 다음과 같은 열이있는 테이블을 생성

:

AssessmentId (PK, FK, int, not null) 
CaseStudyId (PK, FK, int, not null) 
Score (int, not null) 
FollowsCaseStudyId (FK, int, null) 
CaseStudy_CaseStudyId (FK, int, null) 

이것은 CaseStudy_CaseStudyId 열을 제외한 모든 항목에서 문제가 없습니다. 왜 그것이 생성 되었습니까? 그것은 무엇을위한 것인가? 생성을 중지하려면 어떻게해야합니까? 내 생각에 EF는 CaseStudy의 열을 CaseStudyId 열과 자동으로 일치시킬 수 없으므로 고유 한 열을 만들어 두 개의 탐색 속성을 연결합니다.

Answer 1

속성은 AssessmentsCaseStudies 컬렉션에 속한

어떤 이유로 Slauma의 InverseProperty 속성 제안이 작동하지 않았습니다. 생성 된 것 마이그레이션 코드를 추가 사용자들은 일단

modelBuilder.Entity<AssessmentsCaseStudies>() 
    .HasRequired(acs => acs.CaseStudy) 
    .WithMany(cs => cs.AssessmentsCaseStudies) 
    .HasForeignKey(acs => acs.CaseStudyId) 
    .WillCascadeOnDelete(false); 

modelBuilder.Entity<AssessmentsCaseStudies>() 
    .HasOptional(acs => acs.Follows) 
    .WithMany() // No reverse navigation property 
    .HasForeignKey(acs => acs.FollowsCaseStudy) 
    .WillCascadeOnDelete(false); 

: 어떤 일을 한 것은 내 데이터베이스 컨텍스트의 OnModelCreating 방법에 유창함 API를 통해, AssessmentsCaseStudies에있는 두 개의 CaseStudy 탐색 속성 사이의 관계, 그리고 CaseStudy 엔티티를 지정했다 I Add-Migration은 더 이상 CaseStudy_CaseStudyId 열을 추가하지 않고 적절한 외래 키 관계와 함께 FollowsCaseStudyId 열을 추가했습니다.

Answer 2

당신이 당신의 CaseStudy 법인에 AssessmentsCaseStudies 개체의 유형 CaseStudy의 이 탐색 속성과 AssessmentsCaseStudies 컬렉션이 때문에 EF는이 컬렉션에 참조하는 두 CaseStudy 탐색 속성의 결정 수 없습니다. 둘 다 가능할 수 있으며 두 옵션 모두 유효하지만 다른 엔티티 모델과 데이터베이스 스키마가됩니다. 이러한 모호한 상황에서

는 EF 규칙은 실제로 만드는 것입니다 세 관계, CaseStudy의 컬렉션 두 CaseStudy 탐색 속성 중 하나를 참조하지만 세 번째를 가지고하지 않습니다 즉 (그러나 노출 "보이지 않는") 끝점은 AssessmentsCaseStudies입니다. 이 세 번째 관계가 데이터베이스에서 볼 수있는 세 번째 외래 키 (밑줄이있는 외래 키)의 이유입니다. (밑줄은 매핑 규칙을 사용하여 명시 적 구성 또는 데이터 주석이 아닌 무언가가 발생한다는 강력한 증거입니다.)

특성을 적용하여 컨텍스트를 재정의하면 CaseStudy 네비게이션을 지정할 수 있습니다

[InverseProperty("AssessmentsCaseStudies")] // the collection in CaseStudy entity 
public virtual CaseStudy CaseStudy { get; set; } 

당신은 또한 (또는, 당신이 모두 필요하지 않습니다) 컬렉션 측의 속성을 넣을 수 있습니다 :

[InverseProperty("CaseStudy")] // the CaseStudy property in AssessmentsCaseStudies entity 
public virtual ICollection<AssessmentsCaseStudies> AssessmentsCaseStudies { get; set; } 

Answer 3

해결책을 찾으려는 다른 사용자는 이전 답변을 시도했지만 추가 외래 키 열이 남아있는 경우 의도하지 않은 POCO 클래스에서 추가로 정의한 속성을 찾아보십시오 DB 필드에 매핑합니다. 복잡한 get 접근 자처럼 코드 블록이 포함되어 있어도 Entity Framework는 코드를 데이터베이스에 매핑하려고 시도합니다. 속성에 의해 엔티티가 반환되면 외부 키 열이 추가로 발생할 수 있습니다. 안전을 위해 [NotMapped] 속성을 사용하여 이러한 속성을 꾸미거나 메서드로 변환하십시오.