문서 데이터베이스:중복 데이터, 참조 자료 등(특히 MongoDB)

문서 데이터베이스:중복 데이터, 참조 자료 등(특히 MongoDB)

데이터를 두 개의 문서로 분할하는 것이 적절한 데이터 구축 방법인 경우가 많은 것 같습니다.일련의 상점을 위한 것이며 각 고객이 방문한 상점을 저장하고 있다고 가정해 보겠습니다.스토어와 고객은 많은 다른 것들과 상호 작용하기 때문에 독립적인 데이터 조각이어야 하지만, 우리는 그것들을 연관시킬 필요가 있습니다.

따라서 쉬운 대답은 사용자의 ID를 상점 문서에 저장하거나 상점의 ID를 사용자 문서에 저장하는 것입니다.그러나 ID가 유용하지 않기 때문에 표시 목적으로 1-2개의 다른 데이터에 액세스하려는 경우가 종종 있습니다.고객 이름이나 가게 이름 같은 것들.

1. 일반적으로 전체 문서의 복사본을 저장합니까?아니면 필요한 데이터만 저장하시겠습니까?문서의 크기와 필요한 양에 따라 다를 수 있습니다.
2. 중복 데이터가 있다는 사실을 어떻게 처리합니까?데이터가 변경되면 찾아가서 데이터를 검색합니까?로드된 데이터를 일정 간격으로 업데이트하시겠습니까?오래된 데이터를 구입할 수 있을 때만 복제할 수 있습니까?

모든 종류의 '모범 사례' 또는 최소한 이러한 주제에 대한 합리적인 논의에 대한 의견 및/또는 링크를 제공해 주시면 감사하겠습니다.

기본적으로 두 가지 시나리오가 있습니다. 신선한 시나리오와 오래된 시나리오입니다.

새 데이터

중복 데이터를 쉽게 저장할 수 있습니다.중복 데이터를 유지 관리하는 것은 어려운 부분입니다.따라서 가장 쉬운 방법은 중복 데이터를 저장하지 않고 유지 보수 작업을 수행하는 것입니다.이것은 주로 새로운 데이터가 필요한 경우에 유용합니다.참조만 저장하고 정보를 검색해야 할 경우 컬렉션을 쿼리합니다.

이 시나리오에서는 추가 쿼리로 인해 오버헤드가 발생합니다.다른 방법은 중복 데이터의 모든 위치를 추적하고 각 업데이트에서 모든 인스턴스를 업데이트하는 것입니다.여기에는 특히 당신이 언급한 것과 같은 N-to-M 관계에서 간접비도 포함됩니다.따라서 어느 쪽이든 새로운 데이터가 필요한 경우 오버헤드가 발생합니다.당신은 두 세계의 최고를 가질 수 없습니다.

오래된 데이터

오래된 데이터를 저장할 여유가 있다면 훨씬 쉬워집니다.쿼리 오버헤드를 방지하기 위해 중복 데이터를 저장할 수 있습니다.중복 데이터를 유지 관리할 필요가 없도록 중복 데이터를 저장하지 않습니다.적어도 적극적이지는 않습니다.

이 시나리오에서는 문서 간 참조만 저장할 수 있습니다.그런 다음 주기적인 맵 축소 작업을 사용하여 중복 데이터를 생성합니다.그런 다음 별도의 컬렉션 대신 단일 맵 축소 결과를 쿼리할 수 있습니다.이렇게 하면 쿼리 오버헤드를 방지할 수 있지만 데이터 변경 사항을 추적할 필요도 없습니다.

요약

다른 문서에 대한 참조만 저장합니다.오래된 데이터를 사용할 여유가 있는 경우 정기적인 맵 축소 작업을 사용하여 중복 데이터를 생성합니다.중복 데이터의 유지 관리가 복잡하고 오류가 발생하기 쉽습니다.

여기서 답은 데이터가 얼마나 최신 상태여야 하는지에 달려 있습니다.

@Niels는 여기에 좋은 요약을 가지고 있지만, 저는 당신이 "사기"를 칠 수 있다는 것을 주목하는 것이 옳다고 생각합니다.

사용자가 사용한 저장소를 표시하려고 합니다.여기서 분명한 문제는 사용자 b/c 저장소 내부에 저장소를 "포함"할 수 없다는 것입니다. 저장소 자체가 너무 중요합니다.그러나 일부 저장소 데이터를 사용자에 포함할 수 있습니다.

"스토어 이름"과 같이 디스플레이에 원하는 것을 사용하면 됩니다.따라서 사용자 개체는 다음과 같습니다.

{
  _id : MongoID(),
  name : "Testy Tester",
  stores : [ 
             { _id : MongoID(), "name" : 'Safeway' },
             { _id : MongoID(), "name" : 'Walmart' },
             { _id : MongoID(), "name" : 'Best Buy' }
            ]
}

이렇게 하면 일반적인 "그리드" 보기를 표시할 수 있지만 저장소에 대한 추가 데이터를 가져오려면 링크가 필요합니다.

직접적인 질문에 답변하기

1. 중복 없음.
2. 중복 없음.

;)

사용해야 하는 중복 항목은 가중치와 같은 "단순" 값(같은 경우도 있지만 시간이나 공간을 따로 저장하는 것이 더 효율적이지는 않음)과 다른 개체를 참조하는 ID(이는 중복 값이지만 대체하는 중복 개체 데이터보다 훨씬 작고 관리가 용이함)뿐입니다.

이제 여러분의 시나리오에 답을 드리자면, 여러분이 원하는 것은 다대다 관계입니다.여기서 일반적인 솔루션은 StoreUsers라고 하는 세 번째 "통과" 또는 "브리지" 테이블/컬렉션을 만드는 것입니다.

StoreUsers
----------
storeuser_id
store_id
user_id

다른 저장소, 다른 사용자 또는 한 저장소에 있는 여러 사용자에 대한 각 저장소 링크에 대한 레코드를 추가합니다.그런 다음 저장소 또는 사용자에 대해 개별적으로 검색할 수 있습니다.MongoDB도 이 접근 방식을 지지합니다. RDBMS에만 국한된 것이 아닙니다.

언급URL : https://stackoverflow.com/questions/3956756/document-databases-redundant-data-references-etc-mongodb-specifically