RDBMS 사용자를 위한 JSON 데이터 모델링

최종 상태의 예 정규화 접근 방식은 여러 문서에 분산된 단일 송장을 나타냅니다:

이는 직접 CSV 가져오기와 일치합니다. 그리고 InvoiceId 필드는 각 송장 항목 문서의 유사 를 외래 키의 개념과 비슷하게 생각하실 수 있지만, 카우치베이스(및 일반적으로 분산 문서 데이터베이스)는 관계형 데이터베이스와 같은 방식으로 이 관계를 적용하지 않는다는 점에 유의하세요. 이는 분산 시스템의 유연성, 확장성, 성능 요구 사항을 충족하기 위한 절충안입니다.

이 예에서 "자식" 문서는 다음을 통해 부모를 가리키고 있습니다. InvoiceId. 하지만 그 반대일 수도 있습니다. '부모' 문서에는 각 '자식' 문서의 키 배열이 포함될 수도 있습니다.

최종 상태의 중첩 접근 방식은 인보이스를 나타내는 단일 문서만 있으면 됩니다.

"InvoiceId"가 더 이상 객체에 존재하지 않습니다. 항목 배열로 변경합니다. 이 데이터는 더 이상 외국 데이터가 아니라 국내 데이터이므로 해당 필드는 더 이상 필요하지 않습니다.

이를 더 자세히 살펴보기 위해 구축 중인 인보이스 시스템에 대해 몇 가지 가정을 해보겠습니다.

그런 다음 그 지식을 바탕으로 다음과 같은 사실을 알게 됩니다:

따라서 '중첩된 개체'가 적합한 디자인으로 보입니다.

이 규칙은 항상 적용되는 딱딱하고 빠른 규칙이 아니라는 점을 기억하세요. 이는 단순히 시작을 돕기 위한 가이드라인일 뿐입니다. 유일한 '모범 사례'는 자신의 지식과 경험을 활용하는 것입니다.

먼저, '작업' 버킷을 만듭니다. 데이터를 변환하여 '스테이징' 버킷(직접적인 CSV 가져오기)를 '작업' 버킷에 추가합니다.

다음으로 '루트' 문서에 '유형' 필드를 표시하겠습니다. 이것은 문서를 특정 유형으로 표시하는 방법으로 나중에 유용하게 사용할 수 있습니다.

루트 문서에는 "InvoiceNum"이라는 필드가 있고 항목에는 이 필드가 없다는 것을 알고 있습니다. 따라서 이 방법은 안전하게 구분할 수 있는 방법입니다.

다음으로 항목을 수정해야 합니다. 이전에는 숫자만 있는 외래 키가 있었습니다. 이제 해당 값이 새 문서 키를 가리키도록 업데이트해야 합니다.

값에 "invoice::"를 앞에 붙이기만 하면 됩니다. 루트 문서에는 InvoiceId 필드가 없으므로 이 쿼리의 영향을 받지 않습니다.

그런 다음 해당 필드에 인덱스를 만들어야 합니다.

이 인덱스는 다음에 예정된 변환 조인에 필요합니다.

이제 이 데이터를 작동하게 만들기 전에 선택 를 사용하여 미리 보고 데이터가 예상한 대로 조인되는지 확인하세요. N1QL의 NEST 작동합니다:

이 쿼리의 결과는 총 3개의 루트 인보이스 문서여야 합니다.

이제 인보이스 항목은 상위 인보이스 내의 '항목' 배열에 중첩되어야 합니다(간결성을 위해 위 스크린샷에서 축소했습니다).

올바르게 보이는지 확인했다면, 데이터를 '작업' 버킷으로 옮길 수 있습니다. 삽입 명령은 위의 명령에서 약간 변형된 것입니다. 선택 명령을 사용합니다.

N1QL을 처음 사용하는 경우 여기서 몇 가지 주의해야 할 사항이 있습니다:

이 쿼리를 실행한 후에는 '작업' 버킷에 총 3개의 문서가 있어야 하며, 이는 3개의 송장을 나타냅니다.

이제 스테이징 버킷에 오래된 데이터가 포함되어 있으므로 삭제하거나 플러시할 수 있습니다. 또는 더 많은 실험을 위해 계속 보관할 수도 있습니다.