Modelowanie ndb jeden-do-wielu: zalety powtarzania KeyProperty kontra klucz obcy

Question

Moje pytanie dotyczy modelowania relacji jeden-do-wielu w ndb. Rozumiem, że można to zrobić na (przynajmniej) na dwa różne sposoby: z powtarzającą się własnością lub z "obcym kluczem". Poniżej stworzyłem mały przykład. Zasadniczo mamy artykuł, który może mieć dowolną liczbę znaczników. Załóżmy, że tag można usunąć, ale nie można go zmienić po dodaniu. Załóżmy też, że nie martwimy się bezpieczeństwem transakcyjnym.

Moje pytanie brzmi: jaki jest preferowany sposób modelowania tych relacji?

Moje rozważania:

• Approach (A) wymaga dwóch pisze dla każdego znacznika, który jest dodawany do artykułu (jeden dla artykułu oraz jeden dla Tag) natomiast zbliżyć (b) wymaga tylko jeden pisze (tylko Tag).
• Approach (A) wykorzystuje mechanizm buforowania NDB, gdy ściągam wszystkie tagi do artykułu natomiast w przypadku podejścia (b) jest wymagane zapytanie (a dodatkowo niektóre zwyczaj buforowania)

istnieją pewne rzeczy że tu jestem, jakieś inne uwagi, które należy wziąć pod uwagę?

Dziękuję bardzo za pomoc.

Przykład (A):

class Article(ndb.Model): 
    title = ndb.StringProperty() 
    # some more properties 
    tags = ndb.KeyProperty(kind="Tag", repeated=True) 

    def create_tag(self): 
     # requires two writes 
     tag = Tag(name="my_tag") 
     tag.put() 
     self.tags.append(tag) 
     self.put() 

    def get_tags(self): 
     return ndb.get_multi(self.tags) 

class Tag(ndb.Model): 
    name = ndb.StringProperty() 
    user = ndb.KeyProperty(Kind="User") # User that created the tag 
    # some more properties 

Przykład (B):

class Article(ndb.Model): 
    title = ndb.StringProperty() 
    # some more properties 

    def create_tag(self): 
     # requires one write 
     tag = Tag(name="my_tag", article=self.key) 
     tag.put() 

    def get_tags(self): 
     # obviously we could cache this query in memcache 
     return Tag.gql("WHERE article :1", self.key) 

class Tag(ndb.Model): 
    name = ndb.StringProperty() 
    article = ndb.KeyProperty(kind="Article") 
    user = ndb.KeyProperty(Kind="User") # User that created the tag 
    # some more properties 

Answer 1

Pan spojrzał na następujący temat korzystania Structured Propertieshttps://developers.google.com/appengine/docs/python/ndb/properties#structured. Krótka dyskusja o numerach Contact i Addresse może uprościć Twój problem. Zobacz także https://developers.google.com/appengine/docs/python/ndb/queries#filtering_structured_properties. Dyskusje są bardzo krótkie.

Ponadto, patrząc na to, że łączenia są niedozwolone, opcja A wygląda lepiej.

Answer 2

Jak wspomniano wcześniej, nie ma żadnych połączeń w Datastore, więc nie ma zastosowania pojęcie "klucza obcego". Co można zrobić, to użyć klasy Query do wysłania zapytania do magazynu danych o poprawny Tag.

Na przykład, jeśli używasz punktów końcowych, a następnie:

class Tag(ndb.model): 
    user = ndb.UserProperty() 

a podczas wniosek zrobić:

query.filter(Tag.user == endpoints.get_current_user()) 

Answer 3

Approach (A) powinny być preferowane w większości sytuacji. Chociaż do dodania tagu potrzebne są dwa zapisy, prawdopodobnie jest to znacznie rzadsze niż czytanie tagów. Dopóki nie masz dużej liczby tagów, wszystkie powinny pasować do powtarzanej właściwości Key.

Jak już wspomniano, pobieranie tagów według ich kluczy jest znacznie szybsze niż wykonanie zapytania.Ponadto, jeśli trzeba tylko nazwę tagu i użytkownika, można utworzyć tag z User jako klucza nadrzędnego i Name jak id tagu:

User -> Name -> Tag 

do stworzenia tego znacznika, należy użyć:

tag = Tag(id=name, parent=user, ...) 
article.tags.push(tag) 
ndb.put_multi([tag, article]) 

Następnie podczas pobierania tagów

for tag in article.tags: 
    user = tag.parent() 
    name = tag.id() 

Następnie każdy klucz został zapisany w Article.tags będzie zawierać klucz użytkownika i Tag imię! Pozwoli to zaoszczędzić od czytania w Tag, aby uzyskać te wartości.