MongoDB 정규화, 외부 키 및 가입
며칠 동안 MongoDB에 대해 자세히 알아보기 전에, MongoDB에 대해 자세히 알아봐야 할지에 대해 매우 기본적인 질문을 하려고 합니다.기본적으로 nosql에 대한 경험이 없습니다.
문서 데이터베이스의 이점에 대해 조금 읽었는데, 이 새로운 어플리케이션에는 정말 좋을 것 같습니다.많은 종류의 오브젝트(많은 m-to-m 관계)와 서브클래스에 대해 즐겨찾기, 코멘트 등을 하는 것은 항상 귀찮습니다.대처하는 것은 귀찮은 일입니다.
또한 SQL은 매우 중첩되어 있으며 15개의 다른 표보다 훨씬 더 나은 문서로 변환되기 때문에 SQL에서 정의하는 데 어려움이 있습니다.
하지만 나는 몇 가지에 대해 혼란스러워.
데이터베이스를 정규화한 상태로 유지하는 것이 바람직합니까?여러 레코드를 업데이트하고 싶지 않습니다.아직도 사람들이 MongoDB의 데이터베이스 설계에 그렇게 접근하나요?
사용자가 책을 선호하고 이 선택 항목이 사용자 문서에 저장되지만 책이 삭제되면 어떻게 됩니까?외부 키 없이 어떻게 관계를 분리할 수 있을까요?모든 링크를 수동으로 삭제해야 합니까?
사용자가 더 이상 존재하지 않는 책을 선호하고 내가 질의하면 어떻게 됩니까(일종의 가입)?여기서 폴트 톨러런스를 해야 하나요?
MongoDB는 서버 측 외부 키 관계를 지원하지 않습니다. 정규화도 권장되지 않습니다.가능하면 자녀 개체를 부모 개체 내에 포함시켜야 합니다. 그러면 성능이 향상되고 외부 키가 전혀 필요하지 않습니다.이는 항상 가능한 것은 아니기 때문에 DBRef라는 다른 컬렉션의 객체를 참조할 수 있는 특별한 구조가 있습니다.DB가 오브젝트를 읽기 위해 추가 쿼리를 작성해야 하지만 일종의 외부 키 참조를 허용하기 때문에 이것은 그리 빠르지 않을 수 있습니다.
그래도 레퍼런스를 수동으로 처리해야 합니다.DBRef가 존재하는지 확인하는 동안에만 DB는 모든 문서를 검토하여 참조를 찾고 참조 대상이 더 이상 존재하지 않는 경우 해당 참조를 제거합니다.그러나 책을 삭제한 후 모든 참조를 삭제하는 것은 컬렉션당 1개의 쿼리를 필요로 하기 때문에 그다지 어렵지 않다고 생각합니다.
스키마가 더 복잡한 경우 nosql이 아닌 관계형 데이터베이스를 선택해야 합니다.
MongoDB 데이터베이스 설계에 관한 책도 있습니다.MongoDB 문서 설계
업데이트 위 책은 더 이상 구할 수 없지만, MongoDB의 인기로 인해 다른 책들도 꽤 많이 있습니다.모두 링크하지는 않겠습니다.아마존에서 간단하게 검색하면 여러 페이지가 표시되므로 찾는 데 문제가 없을 것입니다.
자세한 내용과 예는 MongoDB 매뉴얼 페이지를 참조하고 DBRefs를 참조하십시오.
위의 @TomaaszStanczak은
MongoDB는 서버 측 외부 키 관계를 지원하지 않습니다. 정규화도 권장되지 않습니다.가능하면 자녀 개체를 부모 개체 내에 포함시켜야 합니다. 그러면 성능이 향상되고 외부 키가 전혀 필요하지 않습니다.그렇다고 항상 가능한 것은 아니다...
정상화는 Mongo에 의해 저지되지 않는다.명확히 하기 위해, 우리는 두 데이터 엔티티가 가질 수 있는 근본적으로 다른 두 가지 유형의 관계에 대해 이야기하고 있습니다.하나의 하위 엔티티는 상위 객체에 의해 독점적으로 소유됩니다.이런 종류의 관계에서 Mongo 방식은 삽입하는 것이다.
다른 종류의 관계에서는 두 개의 실체가 독립적으로 존재한다. 즉, 독립적인 수명과 관계를 갖는다.몽고는 이런 종류의 관계가 존재하지 않기를 바라며 어떻게 대처해야 할지 답답할 정도로 침묵하고 있다.매립은 해결책이 아닙니다.정상화는 권장되거나 권장되지 않습니다.Mongo는 수동 참조(외부 키 구속조건이 2개의 테이블을 바인드하는 키와 유사)와 DBRef(같은 처리를 위한 조금 더 구조화된 다른 방법)의 두 가지 메커니즘만 제공합니다.이 사용 사례에서는 SQL 데이터베이스가 승리합니다.
Tomasz와 Francis의 답변에는 "정규화"는 Mongo에 의해 권장되는 것이 아니라 "문서 참조"를 작성하기 전에 먼저 데이터베이스 문서 설계의 최적화를 고려해야 한다는 좋은 조언이 포함되어 있습니다. DBRefs그러나 Tomasz가 언급한 것처럼 마법의 총알은 아니므로 도움이 되려면 추가 처리가 필요합니다.
현재 MongoDB 버전 3.2에서 가능한 것은 $lookup aggregation pipeline stage 연산자를 사용하여 SQL JOIN과 동등한 결과를 생성하는 것입니다.이렇게 하면 "정규화된" 문서 구조를 만들 수 있지만, 통합된 결과를 생성할 수 있습니다.이 작업을 수행하려면 대상 컬렉션에 의미 있는 고유한 키를 만들어야 합니다.이 필드에 고유한 인덱스를 생성하여 고유성을 적용할 수 있습니다.
$125의 사용은 매우 간단합니다.https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/ #http://https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/ 를 참조해 주세요.를 실행합니다.aggregate()소스 컬렉션의 메서드(즉, "왼쪽" 테이블).from 파라미터는 타겟 컬렉션(즉, "오른쪽" 테이블)입니다.localField 파라미터는 소스 컬렉션의 필드(즉, "외부 키")foreignField 파라미터는 대상 컬렉션의 일치 필드가 됩니다.
고립된 문서에 관해서는, 당신의 질문에서 기존의 RDBMS 제약이나 단계적 삭제 등을 생각하고 있다고 생각합니다.다시 말씀드리지만, MongoDB 버전 3.2에서는 문서 검증을 기본적으로 지원합니다.다음 StackOver 기사를 참조하십시오.MongoDB에서의 제약은 어떻게 적용합니까?두 번째 답을 보세요.조니의 대답입니다.홍콩
Packt Publishers는 MongoDB에 관한 좋은 책을 많이 가지고 있습니다.(완전 공개:몇 개 썼어요.)
언급URL : https://stackoverflow.com/questions/5841681/mongodb-normalization-foreign-key-and-joining
'programing' 카테고리의 다른 글
| WordPress에서 미디어 셀렉터를 add_settings_field에 추가하는 방법 (0) | 2023.02.25 |
|---|---|
| Ruby on Rails - 여러 모델용 JSON 렌더링 (0) | 2023.02.25 |
| 어레이의 필드 값으로 쿼리할 Firestore (0) | 2023.02.25 |
| 순수 css를 사용하는 다른 요소의 너비를 기준으로 스팬의 너비를 설정합니다. (0) | 2023.02.25 |
| AngularJS: 모델에 대한 2방향 바인딩을 선택하지 않음 (0) | 2023.02.25 |