MongoDB를 데이터베이스 스키마 디자인 팁

Question

는

가능한 중복 :

Mongodb database Schema Design with shared data

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

나는 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 의미합니다. 먼저해야 할 일은 스키마 디자인입니다. 내가 할 필요가

쿼리는 다음과 같습니다

는

SELECT D.Prop_Info, D.System_ID, A.Tenant_Info From TENANT A ,System_prop D, SYSTEM B, Where D.System_ID = B.System_ID AND D.Tenant_ID = A.Tenant_ID 

SELECT C.System_ID, C.auth_Info, B.System_ID FROM Authorization C, SYSTEM B WHERE C.System_ID = B.System_ID 

는 사람이 어떻게하여 MongoDB의 컬렉션으로이 테이블을 설계하는 데 도움이 수 있습니까?

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

Answer 1

제공된 스키마 정보에서 Tenant와 System (JOIN 테이블 System_prop을 통해)과 System-Authorization 간의 일대 다 관계가 다 분량 인 관계가있는 것으로 보입니다.

MongoDB에서 이러한 두 유형의 관계는 배열 필드를 사용하여 구현할 수 있습니다.

{ 
    System_Info: ..., 

    Tenant: [ 
     { 
      Tenant_Id: ..., 
      Tenant_Info: ..., 
      Prop_Info: ... 
     }, 
     { 
      Tenant_Id: ..., 
      Tenant_Info: ..., 
      Prop_Info: ... 
     } ], 

    Authorization: [ 
     { 
      Auth_Id: ..., 
      Auth_Info: ... 
     }, 
     { 
      Auth_Id: ..., 
      Auth_Info: ... 
     } ] 
} 

그러나, 임차인 정보를 원하시면, 지금 해제 정규화 된 것이다 중복 된 정보, 즉 같은 임차인 문서가 서로 다른 시스템 문서에 나타납니다 : 이것은 당신의 시스템 모음을 설정할 수있는 방법입니다. 일관성을 보장하는 것은 응용 프로그램의 책임입니다.

귀하가 언급 한 검색어에 대해 : 누락 된 정보가있는 것 같습니다. 첫 번째 쿼리의 경우 Tenant_Id에 참여하지만 Tenant 테이블의 정보는 요청하지 않습니다.두 번째는 Prop_Info을 권한 부여 테이블에서 요청하지만 해당 테이블에는 Prop_Info이 없습니다. 대신 A.Autho_Info이되어야합니까? 따라서 이러한 쿼리를 다시 확인해야 할 수 있습니다. 여기

은 읽기 가치가 MongoDB의에서 스키마 설계에 대한 몇 가지 추가 리소스입니다 : 그것은 정확히 어떻게 응용 프로그램과 가장 자주 쿼리에 따라, 결국

http://www.mongodb.org/display/DOCS/Schema+Design

https://openshift.redhat.com/community/blogs/designing-mongodb-schemas-with-embedded-non-embedded-and-bucket-structures

당신 데이터 저장을 선택하면 위의 예는 스키마를 설정하는 한 가지 방법 일뿐입니다.

Answer 2

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

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