GAE에서 NDB와 컴포지션/애그리 게이션을 구현하는 방법

Question

Google App Engine에서 NDB를 사용하여 애그리 게이션 또는 컴포지션을 구현하는 방법은 무엇입니까? 유스 케이스에 따라 진행하는 가장 좋은 방법은 무엇입니까? 감사합니다.

반복 속성을 사용하려고했습니다. 이 아주 간단한 예제에서, 프로젝트는 Tag 키 목록을 가지고 있습니다 (많은 Project 객체가 Tag 객체를 공유 할 수 있기 때문에 StructuredProperty를 사용하는 대신이 방법으로 코딩했습니다).

class Project(ndb.Model): 
    name = ndb.StringProperty() 
    tags = ndb.KeyProperty(kind=Tag, repeated=True) 
    budget = ndb.FloatProperty() 
    date_begin = ndb.DateProperty(auto_now_add=True) 
    date_end = ndb.DateProperty(auto_now_add=True) 

    @classmethod 
    def all(cls): 
     return cls.query() 

    @classmethod 
    def addTags(cls, from_str): 
     tagname_list = from_str.split(',') 
     tag_list = [] 
     for tag in tagname_list: 
      tag_list.append(Tag.addTag(tag)) 
     cls.tags = tag_list 

-

편집 (2) : 감사합니다. 마지막으로 두 개의 엔티티 사이의 관계를 나타내는 새로운 Model 클래스 'Relation'을 만들도록 선택했습니다. 더 많은 협회였습니다. 저는 첫 디자인이 부적절하다는 사실을 고백합니다.

Answer 1

실제로 사용 사례에 따라 다릅니다. Item의 수가 적을 경우 StructuredProperty 및 반복 속성이 가장 적합 할 수 있습니다.

많은 수의 엔티티의 경우 키 조합에서 부모/조상을 설정하고 KeyProperty가 여러 엔티티의 기본 엔티티를 가리 키도록하십시오.

그러나 선택은 실제 사용 패턴에도 크게 의존합니다. 그렇다면 효율성에 대한 고려가 시작됩니다.

내가 제안 할 수있는 최선의 방법은 이러한 관계를 어떻게 사용할 계획인지, 즉 얼마나 적극적인지 (즉, 끊임없이 변화, 추가, 삭제), 모든 구성원을 볼 필요가 있는지, 대부분의 시간 관계 또는 단지 부분 집합. 이러한 고려는 접근법을 조정할 필요가있다.

Answer 2

다른 대안은 BigQuery를 사용하는 것입니다. 처음에는 집계되지 않은 개별 레코드를 저장하는 RawModel과 NDB를 사용했으며 집계 값을 저장하는 AggregateModel을 사용했습니다.

RawModel이 생성 될 때마다 AggregateModel이 업데이트되어 일부 불일치 문제가 발생했습니다. 뒤늦게, Tim이 제안한대로 부모/조상 키를 올바르게 사용하면 효과가 있었지만 결국에는 BigQuery가 훨씬 더 즐겁고 직관적으로 작업 할 수있었습니다.

우리는 매일 RawModel을 BigQuery에 푸시하고 다른 하나는 BigQuery에서 가져온 데이터가있는 AggregateModel 레코드를 만들기 위해 매일 실행되는 cronjob을 보유하고 있습니다. 나는이 질문을 참조 할 것