Mongodb 데이터베이스 공유 데이터가 포함 된 스키마 디자인

Question

안녕하세요 저는 mongodb에 초보자입니다. 자바를 사용하고 있습니다.

나는 4 개의 테넌트, 시스템, 권한을 내 관계 테이블에 가지고 있습니다.

이와 비슷한 것.

System_prop 테이블에서

Table   Fields 

Tenant   Tenant_ID(PK), Tenant_INFO 
System   System_ID(PK), System_Info 
Authorization System_ID, Autho_Info. 
System_prop  System_ID, Prop_Info, Tenant_ID 

는 Tenant_ID 세입자 표 Tenant_ID (PK)는, SYSTEM_ID 시스템 SYSTEM_ID 표를 말한다 말한다. 승인 테이블에서

는, SYSTEM_ID는 시스템 tabel 내가 MongoDB를하는 관계에서 내 데이터베이스를 전환하고

을 SYSTEM_ID 의미합니다. 먼저해야 할 일은 스키마 디자인입니다. 내가 할 필요가

쿼리는 다음과 같습니다

1. System_prop A, 시스템 B, 임차인 C에서 SELECT A.Prop_Info, A.System_ID 어디 A.System_ID = B.System_ID 및 A.Tenant_ID = C. Tenant_ID

2. SELECT A.System_ID, Authoization A로부터 A.Prop_Info, 시스템 B WHERE A.System_ID = B.System_ID

사람이 어떻게 몽의 컬렉션으로이 테이블을 설계하는 데 도움이 수 odb?

dbref를 사용하고 싶습니다. 이를위한 스키마 설계를 도와주세요.

Answer 1

두 질문 모두에서 Prop_Info을 검색해야한다는 어려움이 있습니다. 이로 인해 어느 몽고 컬렉션이 살고 있는지 파악하기가 어렵습니다.

MongoDB에서는 단일 문서가 쿼리 패턴에 필요한 모든 정보를 갖도록하는 이상적인 목표로 문서 스키마를 만듭니다. 두 개의 별도의 컬렉션을 A 및 B에 대한 두 개의 쿼리에 의해 반환 (예 : 귀하의 경우 Prop_Info로) D 동일한 데이터를 가지고하는 데 필요한 경우, 다음과 같은 세 가지 전략 중에서 선택할 수 있습니다

1. A과 B의 문서에 D을 복제하고 코드와의 일관성을 유지하십시오.이것은 일반적으로 삽입/업데이트 측면에서 추가 코드 복잡성과 Mongo가 ACID가 아니기 때문에 잠재적 인 일관성 문제가 발생하더라도 두 번째 쿼리의 필요성을 없애고 자하는 고성능 시스템의 디자인 선택입니다.

2. D을 A에 입력하고 B에 참조 (DBRef 또는 다른 식별 필드 조합)를 저장하여 두 번째 쿼리로 참조 할 수 있도록하십시오. 이것은 일반적으로 A에 대한 쿼리 수가 B에 대한 쿼리 수를 초과 할 때 디자인 선택입니다. 더 자주 쿼리 된 컬렉션에 로컬로 D을 유지합니다. 이 스키마 디자인 패턴에서는 B을 쿼리 할 때 두 번째 쿼리 만 작성하면됩니다.

3. 은 새 컬렉션 C에 D을 넣고 A 및 B 모두에서에 두 번째 쿼리를합니다. 이것은 일반적으로 위의 (1) 또는 (2)로 가면 트레이드 오프가 무엇인지 명확하지 않은 매우 불확실한 미래 요구 사항에 직면하여 설계 선택입니다. 가장 "관계형"인 스키마이며 A과 B을 모두 쿼리 할 때 두 번째 쿼리를 만들어야하는 스키마입니다. 당신이 선택하는 전략

도메인 쿼리 패턴, (사용하는 경우) 당신이 당신의 객체 관계형 매핑 (ORM) 프레임 워크에서 얻을 지원 그리고 마지막으로, 환경 설정에 따라 달라집니다.

내가 만난 상황에서 나는 결코 (3)을 선택하지 않았습니다. 고성능 상황 (분석 시스템)에서 (1)을 사용했습니다. 나는 쿼리 접근 패턴이 "공유 된"데이터가 살아 있어야하는 곳을 명백하게했기 때문에 (2) 다른 곳에서는 사용하지 않았다.

전략을 선택했으면 도움이 여전히 필요하면 선택한 전략에서 스키마 디자인 문제에 중점을 둔 다른 질문을 게시하십시오.

세 최종 팁 :

1. 관계 다수 1 개보다 큰 이용 배열을 갖는다 D 공유 데이터 경우. 배열 전체를 인덱싱 할 수 있으며 $elemMatch을 사용하여 배열 내부를 정확하게 쿼리 할 수 ​​있습니다.

2. 전략 (1) 또는 (2)에서 D을 업데이트하려면 MongoDB의 atomic modifier operations을 사용하십시오. 대부분이 배열에서 작동하도록 설계되었습니다.

3. This SO question은 @ Stennie의 대답에서 DBRef 두 가지 쿼리 패턴을 다룹니다. (@Stennie는 MongoDB의 마커 인 10gen에서 작동합니다.)

행운을 빈다!

Answer 2

당신은 여전히 ​​관계형 데이터베이스를 생각하고 있습니다. 그러나 MongoDB는 문서 지향 데이터베이스입니다.

1. 모든 문서에는 GUID (전역 적으로 고유 한 것으로 보장 된) 인 _id 필드가 자동으로 생성되므로 인공 ID 번호가 일반적으로 필요하지 않습니다.
2. MongoDB에서 관계 테이블을 사용하지 않아야합니다. n 형 관계는 대신 배열 필드로 만들어집니다. 따라서 하나의 시스템에 N 개의 인증이 사용되면 시스템 문서에는 권한이있는 객체 ID의 배열 인 "인증"필드가 있어야합니다. 그렇습니다. 이것은 관계형 데이터베이스의 정규화 규칙에 대한 끔찍한 위반 일 것입니다. 그러나 여기에는 관계형 데이터베이스가 없습니다. 배열이 쿼리 언어에 투명하기 때문에 MongoDB에서는 배열을 사용하여 N- 관계를 표현하는 것이 실용적입니다.

Answer 3

모든 문서가 포함 된 컬렉션이 하나만 필요할 수도 있습니다. 물론 반복 필드가 너무 많음으로 끝날 수는 있지만 이는 확장의 트릭입니다. MongoDB가 기본 키를 처리하므로 관계 유형이 일대일 및 일대일 일 경우 식별자를 제거하고 나머지 특성을 넣으면됩니다. ('나는 MongoDB를 좋아한다').

임차인과 시스템간에 많은 관계가 있다면 MongoDB 데이터 구조의 배열로 변경해야합니다.

coll{ 
Tenant : 'value', 
tenant_info : 'value', 
Sys_info: 'value' , 
auth_info: 'value' , 
Prop_info : array [ 'value','value',''value....] 
}