Ich weiß, dass diese Antwort etwas spät kommt, aber für MongoDB sehen Sie wahrscheinlich etwas anderes.
Mongo ist schemalos, daher ist das Konzept „tablePerHierarchy“ nicht unbedingt nützlich.
Nehmen Sie Folgendes an
class A
property X
property Y
property Z
class B inherits from A
property W
In einem RDMS würden Sie wahrscheinlich so etwas haben
table A: columns X, Y, Z
table B: columns X, Y, Z, W
Aber MongoDB hat kein Schema. Sie müssen die Daten also nicht auf diese Weise strukturieren. Stattdessen hätten Sie eine "Sammlung", die alle Objekte (oder "Dokumente") vom Typ A oder B (oder C...) enthält.
Ihre Sammlung wäre also eine Reihe von Objekten wie diese:
{"_id":"1", "X":1, "Y":2, "Z":3}
{"_id":"2", "X":5, "Y":6, "Z":7, "W":6}
Sie werden feststellen, dass ich Objekte vom Typ A direkt neben Objekten vom Typ B speichere. MongoDB macht dies sehr einfach. Ziehen Sie einfach ein Dokument aus der Sammlung hoch und es hat "magischerweise" alle entsprechenden Felder/Eigenschaften.
Wenn Sie jedoch "Datenobjekte" oder "Entitäten" haben, können Sie sich das Leben erleichtern, indem Sie einen Typ hinzufügen.
{"_id":"1", "type":"A", "X":1, "Y":2, "Z":3}
{"_id":"2", "type":"B", "X":5, "Y":6, "Z":7, "W":6}
Dies macht es einfacher, eine Factory-Klasse zum Laden Ihrer Objekte zu schreiben.
