Mein Hintergrund beim Entwerfen von Datenspeichern stammt von Core Data unter iOS, das Eigenschaften mit einer Eins-zu-Viele-Beziehung zu einer anderen Entität unterstützt.
Ich arbeite an einem App Engine-Projekt, das derzeit drei Entitätstypen aufweist:
User , das eine Person darstellt, die die App verwendet. Project , das ein Projekt darstellt. A User kann mit vielen Projekten verknüpft sein. Post , welches der Hauptinhalt hinter einem Project ist. A Project kann viele Beiträge haben. Momentan hat User eine Eigenschaft, projects , das ist eine Eins-zu-viele-Beziehung zu Project -Entitäten. Project hat eine Eigenschaft, posts , dh eine Eins-zu-viele-Beziehung zu Post -Entitäten.
Ist in diesem Fall die Referenzeigenschaft von Datastore oder die strukturierte Eigenschaft von NDB für den Job besser geeignet (und wie unterscheiden sich die beiden Konzepte?)? Gibt es eine bessere Möglichkeit, meine Daten zu strukturieren?
Als Referenzeigenschaft meinen Sie wahrscheinlich Schlüsseleigenschaft. Dies ist eine Referenz auf eine andere Datenspeicherentität. Es ist in db und ndb APIs vorhanden. Mit diesen können Sie eine Viele-zu-Eins-Beziehung modellieren, indem Sie viele Entitäten auf den Schlüssel einer anderen Entität verweisen.
Strukturiertes Eigentum ist ein ganz anderes Tier. Sie können eine Datenstruktur definieren und sie dann in eine andere Entität einbeziehen.
Hier ist ein Beispiel aus den Dokumenten, in dem Sie mehrere Adressen für einen einzelnen Kontakt angeben:
%Vor%Für Ihre spezielle Anwendung empfehle ich die Verwendung von NDB (es ist immer am besten, die neueste verfügbare Version der API zu verwenden), mit den folgenden:
Geben Sie das Modell unter Projektmodell als wiederholte strukturierte Eigenschaft ein. Benutzer enthalten eine wiederholte KeyProperty, die die Schlüssel der Projekte enthält, für die sie Berechtigungen besitzen.
Um es ein bisschen komplexer zu machen, können Sie ein anderes Modell erstellen, um Projekte und Berechtigungen / Rollen darzustellen, und es dann als wiederholte strukturierte Eigenschaft in das Benutzermodell einfügen.
Der Hauptgrund, warum Sie sich an die Schlüssel halten wollen, ist, die Daten im Hinblick auf die Konsistenz der HRDs zugänglich zu halten.
Lassen Sie es mich wissen, wenn Sie weitere Hilfe benötigen.
BEARBEITEN:
Um zu verdeutlichen, hier ist die vorgeschlagene Struktur:
Modelle:
Benutzermodell sollte User-Project-Mapping als wiederholte strukturierte Eigenschaft enthalten.
Das Projektmodell sollte Post als wiederholte strukturierte Eigenschaft enthalten.
Benutzer-Project-Mapping muss nur die Schlüsselreferenz für das Projekt und die relevante Berechtigungsdarstellung enthalten.
Da dies wie ein kommerzielles Projekt klingt, wenn Sie weitere Hilfe benötigen, berate ich Sie gerne. Hoffe, du hast genug, um erfolgreich zu sein!
Es gibt einen weiteren Punkt, der nicht erwähnt wurde und relevant sein könnte: Entitäten, die in eine StrukturierteEigenschaft eingefügt wurden, sind keine vollwertigen Entitäten, wie in dieser Teil der Dokumentation . Unten ist das vollständige Zitat (es bezieht sich auf das gleiche Beispiel in der Antwort von @Soloub):
Obwohl die Adressinstanzen mit demselben definiert sind Syntax wie für Modellklassen, sie sind keine vollwertigen Entitäten. Sie Sie haben keine eigenen Schlüssel im Datenspeicher. Sie können nicht abgerufen werden unabhängig von der Kontaktstelle, zu der sie gehören.
Dies kann zu einigen Einschränkungen im Design führen, da Sie die Eigenschaft einer Entität nicht erneut verwenden können, ohne Daten zu duplizieren. Die KeyProperty bezieht sich andererseits auf den Schlüssel einer anderen Entität und stellt daher die Entitätsbeziehung in einer "relationalen" Weise dar. Und KeyProperties kann auch wiederholt werden: Fügen Sie einfach den Parameter repeated=True ein.
Tags und Links python database google-app-engine database-design