NHibernate Composite Key와 Composite Unique Constraint

Question

NHibernate를 사용할 때, 고유 제한 조건을 갖고 그 제한 조건에 의해 고유하게 식별 될 수있는 엔티티가있는 경우, 제한 조건을 복합 키로 나타내거나 별도의 ID 복합 고유 제한이 있습니까? 나는 그것이 도움이 될 수 있고 레거시 데이터베이스로 작업 할 때만 사용되어야한다면 NHibernate와 복합 키를 사용하는 것이 "나쁜"것으로 간주된다는 것을 읽었습니다.

이미지 설정이 다음과 같이 여기

class Book 
{ 
    public virtual int Id { get; protected set; } 
    public virtual string Author { get; set; } 
    public virtual IList<BookEdition> Editions { get; set; } //HasMany (one to many) 
} 

class BookEdition 
{ 
    public virtual string Title { get; set; } 
    public virtual string Language { get; set; } 
    public virtual int Edition { get; set; } 
} 

우리가 언어 및 버전에 제약이있는 BookEdition의 제한을, 즉 같은에서 책의 두 가지 버전이있을 수 없습니다 언어. 모든 판은 판 번호와 언어로 고유하게 식별 될 수 있습니다.

어떤 접근 방식이 NHibernate에서 더 좋은 것으로 간주됩니까? Language/Edition을 복합 Id로 사용하거나 BookEdition에 대한 Id 변수를 도입하고 복합 고유 제한 조건을 대신 사용 하시겠습니까?

Answer 1

일반적으로 NHibernate뿐만 아니라 Surrorgate 키 (추가 ID 변수)가 더 좋습니다. 자연 키 (여기서 : 언어 및 버전)의 문제점은 "비즈니스"라는 의미입니다. 비즈니스 요구 사항은 시간이 지남에 따라 진화하고 앞으로는 자연 키를 변경해야하므로 매우 고통 스러울 수 있습니다. 또한 SQL 조인 및 조건이 더 복잡해집니다.

이

복합 고유 제한 조건으로 BookEdition의 FNH 매핑 될 수있다 : Btw는

Id(x => x.Id); 
    Map(x => x.Title); 
    Map(x => x.Language).UniqueKey("MyCompositeUniqueConstraint"); 
    Map(x => x.Edition).UniqueKey("MyCompositeUniqueConstraint"); 

. 고객에게 중요한 키 값을 표시하지 않는 것이 좋습니다. 그들은 그들에게 약간의 비즈니스 의미를 부여하는 경향이 있습니다.