2011-01-10 2 views
0

나는 문서를 파싱하고 데이터베이스에 저장해야하는 새 프로젝트를 시작하고 있습니다. 이 문서에는 약 10 개의 섹션과 약 100 쌍의 간단한 키 - 값 쌍이 포함되어 있습니다. 섹션 당 하나의 테이블을 가질 수 있으며, 모두 일대일로 집계합니다. 또는 약 100 개의 필드가있는 테이블 하나를 가질 수 있습니다. 나는 하나의 큰 테이블을 만들고 싶지 않기 때문에 붙어 있지만 많은 일대일 맵핑을하고 싶지도 않습니다. 그래서 큰 테이블을 만들거나 작은 테이블을 만들까요? 사실 내가 말할 수있는 한 실제로는 차이가 없을 것입니다. 있다면 알려주십시오.스타일 질문 - 많은 필드가있는 데이터베이스 테이블

편집 예를 들어 도움이 될만한 것이 있습니다.

Document 
    - Section Title 1 
    - k1: val1 
    - k2: val2 
    ... 
    - Section Title 2 
    - k10: val10 
    ... 
    ... 
    - Section Title n 
    - kn-1: valn-1 
    - kn: valn 

그리고 관계형 데이터베이스를 사용해야하므로 별도로 제안하지 않아도됩니다.

+0

예를 들려 줄 수 있습니까? 어느 시나리오도 이상적이라고 들리지는 않습니다. 아마도 당신이하려는 것을 머리 속에 그려 놓은 그림이 없기 때문일 것입니다. –

답변

1

보고, 그리고 수있는이 문서의 각 인스턴스는 그 100의 값을 사용할 경우에 + 열, 그리고 RDBMS 내에서 모든 데이터와 행과 열을 저장하는 데 내재 된 힘과 유연성을 원한다면, 그 모든 것을 하나의 거대한 (비록 추악한) 테이블로 저장할 수 있습니다.

주어진 섹션의 모든 "항목"이 항상 채워지지만 일반 섹션이 채워지거나 채워지지 않을 경우 섹션 당 하나의 테이블을 갖는 것이 가치있을 수 있지만 ... 그런 경우입니다.

위의 "ifs"를 조심하십시오. 그 중 하나라도 너무 불안정하다면, 큰 테이블 아이디어가 가치보다 더 고통 스러울 수 있으며 대체 아이디어 (@ 9000의 NoSQL 아이디어)가 더 나을 수도 있습니다.

+0

NoSQL을 사용할 수 있기를 바랍니다. 그것은 훨씬 더 적합합니다. 하지만 클라이언트가 그것을 지원할 수 없어 그래서 내가 붙어 있어요. 그 거대한 테이블은 모든 형태가 공통으로 가지고있는 것입니다. 그리고 전체 형태가 채워 져야합니다. 부서별 섹션에 대한 다른 테이블이 있습니다. – geowa4

0
Table document(
    PK - a surrogate key 
    name - the "natural" key 
) 

Table content(
    PK - the PK of the parent document 
    section title 
    name 
    value 
) 

예. 문서 당 이름/값 쌍의 행이 100 개 있습니다. 그러나 데이터베이스를 수정하지 않고도 이름과 값을 쉽게 추가 할 수 있습니다.

+0

이 방법을 사용하면 NoSQL 데이터베이스에 이점이있을 수 있습니다. – 9000

0

데이터가 읽기 전용 용도 일 뿐이며 XML에서 DB 체계 변경 (변경)을 요구하지 않는다면 단일 테이블에 대해 비정규 화 된 문제는 보이지 않습니다. 다른 대안은 당신이 큰 문서의 여러 인스턴스 (현재 및/또는 시간이 지남에) 많은 저장하는 경우 EAV models

관련 문제