null 값을 사용하여 Couch DB 뷰를 만드는 데 문제가 있습니까?

Question

저는 여가 시간에 소파 DB를 사용하여 상당한 작업을 해왔고 실제로 사용하는 것을 즐깁니다. 관계형 데이터베이스를 사용하는 것보다 훨씬 유연하다는 것을 알았지 만 단점이없는 것은 아닙니다.

하나의 큰 단점은 동적 쿼리/뷰 생성이 부족하다는 것입니다. 따라서 뷰를 계획하고 정당화 할 때 상당량의 작업을 수행해야합니다. SQL과 관련이 있습니다.

{ 
    "_id": "blah", 
    "type": "user", 
    "name": "Bob", 
    "email": "bob@theaquarium.com", 
    "password": "blah", 
} 

이 중복 계정의 생성을 방지하기 위해, 나는를 생성하는 아주 기본적인보기를 썼다 : 예를 들어

는,이 같은 조금 보이는 JSON 문서 템플릿을 기반으로 로그인 방식을 썼다 조회 할 사용자 이름 목록 :

emit(doc.name, null) 

이것은 나에게 상당히 효율적으로 보였습니다. 나는 그것이 전체 문서 목록을 드래그하는 것보다 더 낫다고 생각한다. 따라서 이메일 주소 목록을 작성하는 것과 똑같은 일을했습니다.

emit(doc.email, null) 

이 질문은 어디에서 볼 수 있습니까?

관계형 데이터베이스 (SQL 사용)에서는 동일한 테이블에 대해 두 번의 쿼리 만 수행합니다. 이 기법 (SQL 쿼리 결과에 대한 뷰를 동일시 함)은 어떤면에서 유사할까요?

성능/효율성 문제가 있습니다 ... 두 가지보기가 실제로 하나 일 뿐이 냐고요? 또는 키와 관련 가치가없는 Couch DB보기를 사용하는 것이 효과적인 방법입니까? 위의 예제를 고려하면 두 뷰 모두 로그인 구성표를 벗어난 용도로 사용됩니다 ... 사용자 이름 목록을 생성해야하는 경우 추가 오버 헤드없이 검색 할 수 있습니다.

당신은 어떻게 생각하십니까?

Answer 1

먼저 을 응용 프로그램 코드에 입력하면됩니다. 응용 프로그램에서 뷰를 추출하고 디자인 문서에 추가하는 적절한 빌드 또는 배포 시스템 만 있으면됩니다. 누락 된 점은 즉석에서 새로운 쿼리를 생성 할 수 있다는 것입니다.

귀하의 emit(doc.field,null) 접근 방식은 확실히 놀랍지도 특이하지 않습니다. 사실, 문서가 include_docs=true을 사용하여 추출되는 "필드로 문서 찾기"쿼리의 일반적인 패턴입니다. 또한 두 개의 뷰를 하나로 결합 할 필요도 없으며 성능 관련 결정은 두 개의 뷰를 동일한 설계 문서에 배치해야하는지 여부 만 결정합니다. 설계 문서의 모든 뷰는 액세스 할 때 업데이트됩니다.

물론 응용 프로그램이 실제로 열심히 노력하더라도 실제로 전자 메일이 고유하다는 보장은 없습니다. 두 클라이언트 응용 프로그램 A와 B를 사용하여 다음 상황을 상상해보십시오.

A: queries view, determines that `test@email.com` does not exist. 
B: queries view, determines that `test@email.com` does not exist. 
A: creates account with `test@email.com` 
B: creates account with `test@email.com` 

이 경우는 거의 발생하지 않지만 가능한 경우입니다. 단일 문서에 대한 액세스가 트랜잭션 적이기 때문에 전자 메일 주소를 사용하는 문서를 유지하는 것이 더 좋습니다 (같은 키로 두 개의 문서를 만드는 것은 불가능합니다).전형적인 예 :

{ 
    _id: "test@email.com", 
    type: "email" 
    user: "000000001" 
} 

{ 
    _id: "000000001", 
    type: "user", 
    email: "test@email.com", 
    firstname: "Test", 
    ... 
} 

편집 : 특정 전자 메일 계정을 만들려고 두 클라이언트가 안정적으로 같은 문서에 액세스하려고 할 경우 예약 패턴에만 작동합니다. 새로운 식별자를 무작위로 생성하면 클라이언트 A는 문서 XXXX를 작성하여 보유하고 클라이언트 B는 YYYY 문서를 작성하고 예약하며 동일한 전자 우편을 갖는 두 개의 서로 다른 문서로 끝납니다.

또한 "모든 클라이언트가 문서를 변경하도록 트랜잭션이"있는 경우 확인, 생성하지 않는 경우 작성 "을 수행하는 유일한 방법입니다.