내 도메인 모델에서 FK를 제거해야합니까?

Question

새로운 프로젝트를 시작하고 nhibernate 사용 계획을 세우고 있습니다. 내 도메인 모델에서 외부 키를 사용하지 않고 지속성 정보를 정리해야하는지 여부에 대해 고민하고 있습니다. 내 "모델"중 일부가 실제로 필요하지 않으며 성능이 문제가 될 것 같은 느낌이 계속됩니다.

내 DB에

나는 다음과 같은 테이블이 있습니다 :

PostingStatus 
    Id 
    Name 

내 모델에서 내가 2 개 클래스를 정의했습니다 :이 테이블과 FK 관계가

Posting 
    Id 
    StatusId 
    ... 

을

예를 들어,

class Posting 
{ 
    virtual int Id { get; set; } 
    virtual PostingStatus Status { get; set; } 
    // .. 
} 

class PostingStatus 
{ 
    virtual int Id { get; set; } 
    virtual string Name { get; set; } 
} 

PostingStatus는 내 모델에 있습니까? 제출 후 게시를 업데이트하는 것과 같이 미리 FK를 알고있는 경우에는 FK를 설정하는 대신 Nhibernate에서 PostingStatus 인스턴스를 가져 오는 것이 꽤 힘든 성과 (또는 쓸모없는 작업)가 아닌가?

저는이 문제가 이전에 논의 된 것으로 확신하지만, 관련성이있는 토론을 조금씩 찾아냅니다. 이 문제에 대한 생각이나 자원은 크게 감사하겠습니다.

Answer 1

도메인 모델에 관계를 적용해야하는 경우 외부 키가 필요합니다.

실제로 성능 문제가 발생할 때까지 성능에 대해 걱정하지 마십시오.

Answer 2

미치가 말한 것. NHibernate는 이러한 문제들을 철저히 생각한 사람들이 모였다. 옳은 일을 할 때, 문제가있는 경우 최적화에 대해 걱정하십시오.

은 (NHibernate에 아마 어쨌든 캐시에서 게시 sttaus를 가져 오는 될 것입니다.)

이 외에도, NHibernate에, 당신이 그것을 설정 한 방법에 따라, 당신의 객체에 데이터베이스를 매핑 FK 제약이 필요할 수 있습니다.

PostingStatus가 도메인 엔터티 인 경우 계속 유지해야합니다. 그것이 아니라면, 그 이유로 제거하십시오. 조기에 최적화하려고하지 마십시오.

Answer 3

이 매우 특별한 경우 실제로 엔티티 PostingStatus를 Enum으로 바꿀 수 있습니다. 열거 형에 대한 값을 적절하게 지정하면 테이블에 매핑하여 FK에 의해 적용될 수 있습니다.

그리고 NH는 '그냥 캐시'하지 않습니다. 나는이 상황을 위해 PostingStatus의 게으른 로딩과 함께 제 2 수준 캐시를 사용할 것을 제안한다.