앱 엔진에서 엔티티 관계와 같은 그래프 모델링

Question

프로젝트 추적 애플리케이션이 있습니다. 이 앱은 다음과 같은 기관이 있습니다 - 특정 프로젝트에

사용자가 속한 -

이야기가

1. 프로젝트를

각 project이 가질 수있는 특정 이야기에 할당, 특정 프로젝트에 속하는 복수 story 및 user 엔티티를 자손으로 사용합니다. story은 복수 user 엔티티의 부모가 될 수 있습니다. 기본적으로 모든 프로젝트에는 프로젝트 내에서 다양한 스토리 (작업)를 수행 할 수있는 여러 사용자가 있습니다. 각 스토리에는 여러 사용자가 할당 될 수 있습니다. 뭔가 아래 같은 :

이

지금 내 질문에, 내가 인덱스 폭발을 유발하지 않고 상위 쿼리를 사용하여 App Engine 데이터 저장소에 이러한 관계를 모델링 할 수있다? 예를 들어, 간단한 쿼리로 프로젝트 내의 스토리를 찾을 수 있습니다. 그러나 특정 사용자에게 할당 된 스토리를 찾으려면 전체 스토리 인덱스를 통과해야합니다 (인덱스 테이블 크기와 무관 한 쿼리 성능으로 인해 실제로 문제가되지는 않음). 그래도 쿼리에 그래프를 반영하는 것이 좋지 않습니다 여기 관계가 좋아? 마치 neo4j 같은 그래프 데이터베이스를 사용하여 모델링 한 것처럼?

Answer 1

사용자가 여러 스토리를 작업하거나 현재 아무 것도 작업 할 수 없거나 자신이 작업하고있는 스토리를 나중에 변경할 수있는 경우 (다른 스토리에 나중에 지정) 스토리를 "상위" 사용자가 의미 론적 수준에서 잘못 판단한 것처럼 보일 수도 있습니다. 쿼리의 종류, 읽기 및 쓰기 빈도 등에 따라 성능 문제가 발생할 수도 있지만, 그럴 수밖에없는 걱정입니다. 의미 론적 정확성을 우선시하고 데이터 모델의 특정 의미에 대해 완전히 확신하지 못합니다.

GAE의 데이터 저장소에있는 부모 "관계"는 영구적 인 모델을 만들기위한 것입니다. (실제로는 "영구", 즉 하위 엔티티의 수명 :-) 1 : 많은 연결, 특히 부모와 자식, 또는 형제 간의 거래 행동 (또는 강한 일관성)을 필요로합니다 (트랜잭션 동작 및 강력한 일관성은 성능면에서 무료로 제공되지 않지만 필요할 때 필요합니다).). 앱의 스토리와 사용자 간의 연결이이 요약과 얼마나 잘 일치합니까?

물론 영구적 인 1 : 많은 연결을 모델링 할 수있는 다른 방법이 있습니다. ndb 개념을 사용하면 StructuredProperty이 실제로 "자식"엔터티를 "부모"개체에 포함시킬 수 있습니다. 그리고 자식 특성에 대한 쿼리가 필요하지 않으면 을 사용하여 속도 향상을 얻을 수 있습니다 로컬 구조화 된 속성의 종류).

물론 모든 종류의 관계를 모델링하는 가장 일반적인 방법은 관계가 영구/영구적 일 필요는없고 반드시 1 : 많은 관계가 필요하지 않은 KeyProperty입니다 (예 : 사용자가 여러 이야기들). 실제로 엔티티가 노드 인 유향 그래프의 주요 특성을 전체 일반으로 볼 수 있습니다 (실제로는 멀티 - 지향 그래프, 노드 A에서 노드 B까지 0 이상의 에지가있는 경우). "단순한"그래프가 제공 할 수있는 것보다 더 일반적인 :-). 그러나 당신이 정말로 그것을 필요로하지 않고 그것을 사용하지 않는다면 당신은 그런 넓은 일반성에 대해 약간의 대가를 지불 할 수 있습니다.

엔티티 관계 모델링 (어떤 종류의 데이터베이스가 기본이든 관계없이 좋은 것 :-)의 완전한 명쾌함을 넘어 결국 "스키마"(넓은 의미의 단어 : -) NoSQL 데이터베이스에 대한 의존성은 어떤 쿼리, 업데이트, &c에 의존적입니다. 응용 프로그램은 대기 시간, 트랜잭션 요구 사항, 일관성 (강건 대 최후)에 대한 허용 빈도와 함께 다음을 요구합니다. 관계형 데이터베이스는 우리 중 대부분이 "우리의 이빨을 자른다"고 생각하는 것입니다. 따라서 두 가지 측면 모두를 매우 명료하게 만들기 위해 노력하는 것이 좋습니다. 물론 추상화의 E-R 계층은 물론 쿼리, 업데이트, &c 및 이들에 대한 제약 조건 및 요구 사항이 혼합되어 있습니다.