Sé que esta respuesta llega un poco tarde, pero para MongoDB, probablemente esté viendo algo ligeramente diferente.
Mongo no tiene esquema, por lo que el concepto de "tablePerHierarchy" no es necesariamente útil.
Suponga lo siguiente
class A
property X
property Y
property Z
class B inherits from A
property W
En un RDMS probablemente tendría algo como esto
table A: columns X, Y, Z
table B: columns X, Y, Z, W
Pero MongoDB no tiene un esquema. Por lo tanto, no necesita estructurar los datos de esta manera. En su lugar, tendría una "colección" que contiene todos los objetos (o "documentos") de tipo A o B (o C...).
Así que tu colección sería una serie de objetos como este:
{"_id":"1", "X":1, "Y":2, "Z":3}
{"_id":"2", "X":5, "Y":6, "Z":7, "W":6}
Notará que estoy almacenando objetos de tipo A justo al lado de objetos de tipo B. MongoDB lo hace muy fácil. Simplemente abra un Documento de la Colección y "mágicamente" tiene todos los campos/propiedades apropiados.
Sin embargo, si tiene "objetos de datos" o "entidades", puede facilitarle la vida agregando un tipo.
{"_id":"1", "type":"A", "X":1, "Y":2, "Z":3}
{"_id":"2", "type":"B", "X":5, "Y":6, "Z":7, "W":6}
Esto facilita la escritura de una clase de fábrica para cargar sus objetos.
