1

ID, 이름, 설명과 같은 몇 가지 공통 필드를 공유하는 유형 세트가있는 데이터 모델에서 작업하고 있습니다. 더 구체적으로 말하자면 :TPH 대 TPT 및 OR 매퍼

Document 클래스는 Attributes 목록을 가지고있다. 이러한 속성은 String, Integer, DateTime과 같은 유형이며 Address 및 String, Integer, Address 등의 목록과 같은 "복잡한"유형입니다. 이제 머리 속에 Attribute 클래스를 모델링하여 공통 속성 (Id, Name, Description)을 포함하는 추상 기본 클래스 (AttributeBase). 그런 다음 적절한 하위 클래스에서보다 구체적인 속성을 갖습니다. 예 : StringAttribute (값), IntegerAttribute (값), AddressAttribute (거리 등), StringListAttribute, IntegerListAttribute, AddressListAttribute. 우리는 15-20 개의 하위 클래스에 대해 이야기하고 있습니다. 그러나 데이터베이스에서 이러한 클래스를 어떻게 모델링합니까? TPH, TPT 또는 TPC를 선택 하시겠습니까? TPT 및 EF 4.1을 선택할 때 성능에 대해 읽었으며 성능이 더 좋더라도 TPH에 대한 하나의 massiv 표가 나에게 소리가 나지 않습니다. 우리는 테이블에 잠재적으로 10000 - 1000000 ++ 행의 데이터에 대해 이야기하고 있습니다.

이러한 시나리오를 처음 접하는 경험이 있습니까? 나는이 주제에 대해 당신이 정말로하고 싶습니다.

답변

3

TPH는 DB 관점에서는 좋지 않지만 실제로는 이러한 유형의 메타 데이터를 사용하는 많은 제품에서 사용되는 저장소 모델입니다. 단일 테이블에 모든 데이터가 들어있는 SharePoint (2007)의 예가 더 복잡한 모델이지만 기본은 동일합니다. 나는 SharePoint와 데이터 저장 방법을 좋아하지 않지만 문제에 대해 생각함으로써 방대한 양의 데이터를 지원하는 일반적인 솔루션 모델을 만드는 데 더 나은 솔루션을 찾지 못했습니다.

TPT 및 TPC는 DB에서 표준화 된 것처럼 보이지만 용도가 느리게 적용됩니다. 또한 Id, NameDescriptionId 및 정수 Value의 두 번째 테이블을 정규화하면 대부분의 경우 표준화 된 IMHO 이상입니다.

btw. 문서를 가지고 무엇인가를하고 있고 문서에 속성을 할당하고 싶다면 반드시 Sharepoint를 체크해야합니다.

+0

감사합니다. 솔루션에서 TPH 관련 성능 문제가 있습니까? – OKB

+0

TPH는 TPC 및 TPT와 비교할 때 쿼리 성능에 가장 작은 영향을 미칩니다. EF 자체가 큰 성능 영향을 추가하므로 EF에 만족하면 성능 문제가 필요하지 않으므로 TPH에 대해 생각하십시오. –

+0

확인. 내 질문에 답변 해 주셔서 감사합니다. – OKB