2

나는 직업 공석을 저장하는 기존 데이터베이스 디자인을 가지고 있습니다.DB 디자인 패턴 - 다 대다 분류/분류 된 태깅

"공석"테이블에는 "제목", "설명", "급여 범위"와 같은 모든 클라이언트에서 여러 고정 필드가 있습니다.

"관리자 이름", "근무 시간"과 같이 클라이언트가 직접 설정할 수있는 "사용자 지정"필드에 대한 EAV 디자인이 있습니다. 필드 이름은 "ClientText"테이블에 저장되고 VacancyId, ClientTextId 및 Value가있는 "VacancyClientText"테이블에 저장된 데이터입니다.

마지막으로 공석이있는 위치/사무실과 같은 것들로 공석을 분류/분류하기위한 많은 EAV 설계가 있습니다. 필요한 기술 목록입니다. 이 값은 각 카테고리 (예 : "London, Paris, New York, Rome", "C#,")의 유효한 값을 나열하는 "ClientCategoryItem"테이블, "Locations, Skills"태그 유형을 나열하는 "ClientCategory" VB, PHP, Python "으로 변경되었습니다. 마지막으로 공석에 대해 선택한 각 항목에 대해 VacancyId 및 ClientCategoryItemId가있는 "VacancyClientCategoryItem"테이블이 있습니다.

클라이언트가 추가 할 수있는 사용자 지정 필드 또는 사용자 지정 범주 수에는 제한이 없습니다. 지금 그러나, 기존의 시스템과 매우 유사 새로운 시스템을 설계하고


, 나는 사용자의 수는 클라이언트가 가질 수있는 필드를 제한 할 수있는 능력을 가지고 있고 더이 그래서는 처음부터 내장되고 있지 있어요 처리 할 기존 문제.

사용자 정의 필드의 경우 내 솔루션은 간단하며 공휴일 테이블에는 CustomField1-5라는 추가 열이 5 개 있습니다. 이렇게하면 EAV 디자인 중 하나가 제거됩니다.

내가 고심하고있는 태깅/분류 디자인이 있습니다. 클라이언트를 5 가지 범주/유형의 태그로 제한하면. 가능한 값 "CustomCategoryItems1-5"를 나열한 다음 5 개의 많은 테이블 "VacancyCustomCategoryItem1-5"

값을 나열하는 5 개의 테이블을 만들어야합니다. 그러면 기존 시스템의 세 테이블과 동일한 저장소를 수행하는 10 개의 테이블이 생성됩니다 .

또한 (천천히 금지해야합니다.) 5 개가 아닌 6 개의 사용자 정의 카테고리가 필요하다면 코드 변경이 많이 발생합니다.


따라서 누구나 그러한 데이터를 저장하는 데 더 적합 할 수있는 DB 디자인 패턴을 제안 할 수 있습니까? EAV 접근 방식을 계속 사용하게되어 기쁩니다. 그러나 기존 시스템은 일반적인 성능 문제와 그러한 디자인과 관련된 복잡한 쿼리를 발견했습니다.

모든 조언/제안 사항을 보내 주시면 감사하겠습니다.

사용되는 DBMS 시스템은 SQL Server 2005이지만 특정 패턴에 필요한 경우 2008은 옵션입니다.

+0

작은 줄에 문제를 넣을 수 있다면 처음에는 문제가 없을 것입니다. 질문은 설계 질문이므로 불행히도 조언을 구하는 유일한 방법은 가능한 한 요구 사항에 대한 많은 정보를 자세히 설명하는 것입니다. –

+0

이 질문은 많은 EAV 패턴의 결과를 반환하는 쿼리를 작성할 때 얻는 성능 문제를 보여줍니다. 여기의 응답은 "하지 마라." http://stackoverflow.com/questions/2386577/sql-server-query-performance-clustered-index-seek –

답변

1

XML 열 사용에 대해 생각해 보셨습니까? XSL을 통해 모든 제약 조건을 선언적으로 적용 할 수 있습니다.

EAV 대신 스키마 (또는 스키마 모음)로 검증 된 XML 데이터가있는 단일 열을 지정하십시오.

+0

XML을 고려하고 있습니다. 필자는 스키마가 아닌 여러 가지 상황에 사용했지만 결코 EAV의 대안으로 많이 사용하지 않았습니다. 나는 이것에 대한 조사를하고 어떻게 느끼는지 보게 될 것이다. –

0

왜 키 - 값 테이블에 사용자 정의 필드를 저장하지 않습니까?

| vacancy ID | CustomFieldType | CustomFieldValue | 

가 그런 종류 당 (1 표)를 사용할 수있는 값을 나열 auxillary 테이블을 가지고 공석 유형에 따라 가능한 유형이 될 수 있습니다

+0

이것은 맞춤 one-to-one 필드에서의 현재 EAV 접근 방식입니다. EAV 접근법을 단순화 및 성능 향상에 도움이되는 고정 된 열로 만들어 버릴 수 있습니다. 그러나 옵션을 찾고있는 것은 많은 분야에서 많은 분야입니다. –

+0

@Robin - 죄송 합니다만,이 접근 방식이 현명한 디자인과 현명한 디자인 모두 최선입니다 ... 물론 선택 : – DVK

+0

이 질문은 그 결과를 반환하기 위해 쿼리를 작성할 때 얻는 성능 문제를 보여줍니다 EAV 패턴이 많거나 많습니다. 여기의 응답은 "하지 마라." http://stackoverflow.com/questions/2386577/sql-server-query-performance-clustered-index-seek –

1

살펴 at this 질문/대답을 가지고 (원래 ClientCategory 것 같다); 관측 패턴을 설명합니다. 5 개의 테이블을 사용하며 "표준"RDBMS로 구현할 수 있습니다 - Sql Server 2005가 수행합니다. 엔티티가 가질 수있는 사용자 지정 속성 (관측)의 수에는 제한이 없습니다.

편집

태그 (범주) 속성에 필요한 경우를 살펴 at this one을.