엔티티 메타 데이터 저장 아키텍처

Question

우리는 문서 저장 및 각 문서에 대해 제목이나 설명과 같은 기본 데이터 또는 관련 이벤트의 날짜에 이르기까지 현지 규정을 준수하기 위해 많은 추가 메타 데이터를 저장해야하는 솔루션을 구축하고 있습니다. 처분 및 분류 규칙.

나는 솔루션의 다른 유형을 본 적이 있지만 아무도 나를 설득하지 : 새로운 메타 데이터 슬롯이 추가된다 (그래서 그들은 문서와 관련된 메타 데이터 많은 열이) 때 열 성장

1. 테이블
2. 스페어 제네릭 열이 많은 테이블. 1.와 매우 유사하지만 테이블이 커지지 않습니다 (사용 권한이 적음)
3. 문서 ID, 메타 데이터 키 및 메타 데이터 값 테이블.
4. 3. 메타 데이터 정의 및 메타 데이터 키가있는 테이블이 메타 데이터 ID로 대체됩니다. 우리는 과거에이 솔루션을 사용했습니다. 테이블에는 끝에 수백만 개의 행이 있습니다.
5. 모든 메타 데이터가 키 - 값 쌍으로 저장된 XML 또는 기타 구조화 된 정보를 저장하는 문서 테이블 또는 관련 테이블의 텍스트 필드입니다.

관련 메타 데이터로 검색 할 수있는 병렬 전체 텍스트 색인 (Lucene.Net? Other?)을 제공합니다 (모든 것이 "검색 가능"하지 않아야 함).

의견이 있으십니까? 비슷한 경험?

Answer 1

표 1 : 문서 정보 (PK는 문서 ID 임)

표 2 : 메타 데이터 정의 (PK는 메타 데이터 정의 ID)

표 3 : 문서 ID 메타 데이터 (고화질)의 ID, 메타 데이터 값

가장 큰 단점은 하나의 유형 (varchar, 아마도)이 있어야하거나 n 열 (n은 저장하려는 데이터 유형의 수)을 가져야한다는 것입니다. 메타 데이터 정의 테이블의 열을 사용하여 값을 가져올 테이블 3의 열을 식별합니다. 나열된 5 개 솔루션에 대한

내 의견 :

1. 성장 표 (당신은/원하는 nullable이 아닌 메타 데이터 값이 필요한 경우 특히) 고통, 그리고 선 아래로 문제가 발생할 수 있습니다.
2. I 싫어 열정이있는 '예비 일반 열'(비록 인기가 있지만).
3. 닫기,하지만 내 솔루션보다 훨씬 더 많은 메타 데이터 유연성을 제한합니다. 메타 데이터 키와 값이 매우 기본 적이면 작동 할 수 있습니다.
4. 나는이 단어가 의미하는 바를 잘 모르겠다 - 제안하는 것과 다른 것인가?
5. 구조화 된 XML을 RDBMS에 저장하는 것이 좋지 않습니다.이 IMHO를 수행하면 RDBMS의 기능을 대부분 잃을 수 있습니다.

그건 내 생각입니다. 저는 이런 식의 시스템을 설계 한 적이 없지만 이러한 구성표 중 몇 가지를 사용한 상용 시스템을 다루었습니다.

Answer 2

CouchDB을 사용하지 않으시겠습니까? 이 유형의 요구 사항을 정확하게 처리하도록 설계되었습니다.

옵션이 아닌 경우 메타 데이터 설명 자로 Lua 또는 JSon (# 5 옵션 별)을 사용하는 것이 좋습니다.

Answer 3

어쩌면 JCR (자바 컨텐츠 저장소)을 살펴볼 수 있습니다. JCR은 버전 관리, 전체 텍스트 검색 및 편집과 같은 컨텐츠 관리의 공통 요구 사항을 캡처하는 컨텐츠 리포지토리의 표준입니다. 또한 콘텐츠 저장소에 추상 수준을 제공합니다. 즉, 하나의 API를 사용하여 데이터베이스, XML 파일 등과 같이 모든 유형의 저장소 시스템에 내용을 넣을 수 있습니다. 물론 속성을 추가하여 문서에 메타 데이터를 추가 할 수 있습니다. JCR API가있는 문서 노드. 문서와 메타 데이터를 저장하는 방법에 대해 걱정할 필요가 없습니다. JCR이 처리 할 것입니다. Jackrabbit은 JCR의 참조 구현입니다. 시도 해봐.