MongoDB 스키마 임베딩 및 중첩 된 고유 키

Question

MongoDB로 변경되는 관계형 SQL DB가 있습니다. SQL에는 Farm, Division, Wombat (이 질문에 대해 변경된 이름과 목적)과 관련된 세 개의 테이블이 있습니다. 또한 사용자 테이블과 동일한 Farmer 테이블이 있습니다.

var mongoose = require('mongoose'); 
var farmSchema = new mongoose.Schema({ 
    // reference to the farmer collection's _id key 
    farmerId: mongoose.Schema.ObjectId, 
    name: String, // name of farm 
    division: [{ 
     divisionId: mongoose.Schema.ObjectId, 
     name: String, 
     wombats: [{ 
      wombatId: mongoose.Schema.ObjectId, 
      name: String, 
      weight: Number 
     }] 
    }] 
}); 

(지금) 중첩 컬렉션의 각 그것에 고유 필드가 있습니다 :

나는이 새 스키마로 왔어요 몽구스 사용. 이렇게하면 Ajax를 사용하여 weightI 만 변경하고 체중이 바뀔 때 전체 문서를 업데이트하는 대신 해당 값을 조정하는 가중치 (예 :)를 보낼 수 있습니다.

MongoDB에 대한 SQL 적용이 잘못된 것 같습니다. 이 작업을 수행하는 더 좋은 방법이 있습니까?

Answer 1

일반적으로 사람들은 MongoDB를 사용할 때 사람들이 너무 많이 퍼지는 경향이 있다고 생각합니다.

가장 중요한 논쟁은 동일한 객체에 대해 서로 다른 작성자를 사용하는 것이 훨씬 복잡한 작업이라는 것입니다. 배열과 임베디드 객체로 작업하는 것은 까다로울 수 있으며, 예를 들어 positional operator matching in nested arrays이 없기 때문에 일부 수정이 불가능합니다.

특정 시나리오의 경우 고유 한 배열 키 might not behave as expected에주의하고 그 동작은 change in future releases 일 수 있습니다.

이 같은

삽입은 매우 올바른 접근 방식을인지 여부

Farm { 
    _id : ObjectId("...") 
} 

Division { 
    _id : ObjectId("..."), 
    FarmId : ObjectId("..."), 
    ... 
} 

Wombat { 
    _id : ObjectId("..."), 
    DivisionId : ObjectId("..."), 
    ... 
} 

가 사용 패턴, 데이터 크기, 동시 쓰기, 등등에 따라 간단한 SQL과 같은 스키마을 선택하는 것이 바람직입니다 - a는 SQL과의 주요 차이점은 there is no one right way to model 1:n or n:n relationships이므로 각 시나리오에 대해 장단점을주의 깊게 고려해야합니다. 내 경험상 고유 ID를 갖는 것은 문서가 '일급 시민'이어야하고 자체 컬렉션이 있어야한다는 매우 강력한 지표입니다.