I know this answer is a little late, but for MongoDB, you're probably looking at something slightly different.
Mongo is schemaless, so the concept of "tablePerHierarchy" is not necessarily useful.
Assume the following
class A
property X
property Y
property Z
class B inherits from A
property W
In an RDMS you would probably have something like this
table A: columns X, Y, Z
table B: columns X, Y, Z, W
But MongoDB does not have a schema. So you do not need to structure data in this way. Instead, you would have a "collection" containing all objects (or "documents") of type A or B (or C...).
So your collection would be a series of objects like this:
{"_id":"1", "X":1, "Y":2, "Z":3}
{"_id":"2", "X":5, "Y":6, "Z":7, "W":6}
You'll notice that I'm storing objects of type A right beside objects of type B. MongoDB makes this very easy. Just pull up a Document from the Collection and it "magically" has all of the appropriate fields/properties.
However, if you have "data objects" or "entities", you can make your life easier by adding a type.
{"_id":"1", "type":"A", "X":1, "Y":2, "Z":3}
{"_id":"2", "type":"B", "X":5, "Y":6, "Z":7, "W":6}
This makes it easier to write a factory class for loading your objects.