스키마를 배열 또는 해시 필드로 저장하면 어떤 이점이 있습니까?

Question

이것은 DB를 재고하는 데 적용됩니다. 임베디드 배열이나 해시 필드가있는 스키마를 배열로 갖는 것이 더 좋습니까? 내 의도를 간단하게 유지. 나는 매일 통계를 추적하려고 노력 중이다. 그러나 나는 어떤 스키마 구조가 더 나은지를 결정할 것입니다. ... 제가 정성 들여 보자

순수 배열 스키마 :

schema = [ 
    { 
    title: 'foobar', 
    dates: [ 
     { 
     date: 20130926, 
     views_count: 10, 
     click_count: 10 
     }, 
     { 
     date: 20130927, 
     views_count: 20, 
     click_count: 20 
     }, 
     { 
     date: 20130928, 
     views_count: 30, 
     click_count: 30 
     } 
    ] 
    } 
] 

해시 필드 배열 스키마 : 내가 생각할 수있는

schema = [ 
    { 
    title: 'foobar', 
    dates: [ 
     '20130926' => { 
     views_count: 10, 
     click_count: 10 
     }, 
     '20130927' => { 
     views_count: 20, 
     click_count: 20 
     }, 
     '20130928' => { 
     views_count: 30, 
     click_count: 30 
     } 
    ] 
    } 
] 

하나는 그것은과 날짜의 이중성을 방지하기 위해 쉽게 ...입니다 후자. 다른 이점들? 또는 개발자가 선호하는 공통된 규칙이 있습니까?

Answer 1

IMHO, 귀하의 신청서는 DBMS보다 우선합니다. DB 스토리지 선택에 초점을 맞추는 대신 어플리케이션 요구, 프로그래밍 및 성능에 중점을 둡니다. 프로그램 데이터를 유지 한 다음 필요할 때만 스키마 변경으로 주요 사례를 반복적으로 벤치 마크하고 최적화합니다. 신청서는 저장 질문에 대한 답변을 제공합니다. 예를 들어, 일반적으로 :

(1) 주로 날짜에 대한 액세스 권한을 주문해야하는 경우, 당신은 많은 날짜에 대한 빠른 랜덤 액세스를 필요로하는 경우 (2), 다음 해시에게

모두 프로그래밍 언어를 사용하여 배열 를 사용 및 DBMS의 의미가 중요합니다. DB가 해시를 주문 했더라도 언어가이 값을 잃을 수 있습니다 (예 : Ruby 1.9의 Hash 이상). 이전에는 순서가 지정되지 않았지만 정렬되었습니다.

물론 스키마 선택은 매우 중요합니다. 하지만 IMHO는 문서의 주요 강점 (비 원주 형 객체 데이터 NoSQL) DBMS는 프로그래밍 언어로 자연스러운 데이터 구조를 매치 할 수있는 능력입니다. 따라서 질문과 답변의 초점으로 응용 프로그램/프로그램으로 돌아가시기를 천천히 권장합니다.