Filtern einer übergeordneten Entität mithilfe der Eigenschaften der untergeordneten Entität im Datenspeicher

Question

Ich verwende Google App Engine (Java) für mein REST-Back-End und google-datastore als Datenbank und verwende objectify für den Zugriff auf die Datenbank.

Ich möchte eine Einheitenentität zum Speichern von Einheiten erstellen, wobei eine Einheit eine Komponente oder eine zusammengesetzte Einheit sein kann. Im Grunde besteht eine zusammengesetzte Einheit aus mehreren Komponenten und besitzt auch einige eigene Eigenschaften. Es kann mehrere Arten von zusammengebauten Einheiten und mehrere Arten von Komponenten geben. Die Entity-Klasse wäre so etwas wie

public class UnitEntity { 
Long unitId; 
String serialNumber; 
String state; 
String unitType; 
Long parentId;// -> this would be null for all assembled units and in case of components, if they are part of any assembled unit, it will be the Id of the assembled unit (This is added so that I can list all components of a particular assembled unit) 
UnitParameters unitParameters; 
} 

Hier UnitParameters wäre eine polymorphe Klasse seines spezifische Eigenschaften für einen Gerätetyp enthalten, das heißt, basierend auf dem Wert von „unittype“, gäbe es verschiedene Klassen sein, die erweitern "UnitParameter".

Nehmen wir an, dass die Komponenten (sagen wir component1, dh unitType = component1) eine Eigenschaft namens modelNumber haben. Diese Eigenschaft wird in den UnitParametern aller Entitäten gespeichert, für die unitType = component1 gilt.

Jetzt möchte ich in der Lage Einheiten aufzulisten, wo unitType = assemblyUnit1 und die eine untergeordnete Komponente1, deren modelNumber 2.0 ist.

(Ich kann leicht Liste Einheiten vom Typ Komponente1, wo Modellnummer ist 2.0, aber ich möchte in der Lage sein, auch die Muttergesellschaft zu erhalten)

Also im Grunde hier versuche ich, Muttergesellschaften zu erhalten, indem Sie auf der Filterung Eigenschaften von Kindern. Ich möchte wissen, ob dies mit Datenspeicher möglich ist und objektivieren? Gibt es eine Möglichkeit, diese Funktionalität zu erreichen?

Update - Follow-up-Frage auf der Grundlage der Antwort von @stickfigure:

Wenn ich mit Google Cloud SQL gehen (die auf MySQL basiert) für meinen Anwendungsfall, dann, wie sollte ich meine Daten modellieren ?

Ich dachte anfangs, eine Tabelle für jeden UnitType zu haben. Nehmen wir an, es gibt 3 unitTypes - assemblyUnit1, assemblyUnit2 und component1. Wenn ich nun eine API haben möchte, die die Details jeder Einheit auflistet, wie kann ich das mit Cloud SQL erreichen?

Dies ist etwas, das ich mit dem Datenspeicher hätte tun können, da alle Entitäten von derselben "Art" waren.

Ich kann natürlich separate APIs haben, um alle Einheiten vom Typ assemblyUnit1, assemblyUnit2 etc. aufzulisten, aber wie kann ich eine einzige API haben, die alle Einheiten auflisten könnte?

Auch wenn in diesem Ansatz jemand die REST-API GET/units/{unitId} aufruft, würde ich wohl in jeder der Tabellen nach der unitId suchen müssen, die nicht korrekt zu sein scheint?

Ich nehme an, eine Möglichkeit, dies zu lösen, ist, nur eine Tabelle namens "Unit" zu haben, deren Spalten eine Obermenge der Spalten aller unitTypes wären. Ich denke jedoch nicht, dass dies eine gute Art des Entwurfs ist, da es für jede Zeile viele leere Spalten geben würde und auch das Schema geändert werden müsste, wenn ein neuer unitType hinzugefügt wird.

Answer 1

Der Datenspeicher führt keine Joins durch. Sie haben also zwei Möglichkeiten: Entweder Sie verbinden sich selbst mit dem Holen oder 2) denormalisieren Sie einige der Kinddaten in den Eltern und indizieren Sie sie dort. Welche Strategie am besten funktioniert, hängt von der Form Ihrer Daten und der Leistung/Kosten ab.

Ich sollte hinzufügen, gibt es eine dritte Option, die "einen externen Index von einigen Ihrer Daten in einer anderen Art von Datenbank speichern, wie die Suche API oder ein RDBMS".

Dies ist nicht immer eine sehr befriedigende Antwort - die Möglichkeit, Joins und Aggregationen in einem RDBMS durchzuführen, ist unglaublich nützlich. Wenn Sie stark relationale Daten mit geringen Anforderungen an Größe/Datenverkehr/Zuverlässigkeit haben, sollten Sie stattdessen etwas wie Cloud SQL verwenden.