Wiem, że ta odpowiedź jest trochę spóźniona, ale w przypadku MongoDB prawdopodobnie patrzysz na coś nieco innego.
Mongo jest pozbawione schematów, więc koncepcja „tablePerHierarchy” niekoniecznie jest przydatna.
Załóżmy, co następuje
class A
property X
property Y
property Z
class B inherits from A
property W
W RDMS prawdopodobnie miałbyś coś takiego
table A: columns X, Y, Z
table B: columns X, Y, Z, W
Ale MongoDB nie ma schematu. Nie musisz więc organizować danych w ten sposób. Zamiast tego miałbyś „kolekcję” zawierającą wszystkie obiekty (lub „dokumenty”) typu A lub B (lub C...).
Twoja kolekcja byłaby więc serią obiektów takich jak ta:
{"_id":"1", "X":1, "Y":2, "Z":3}
{"_id":"2", "X":5, "Y":6, "Z":7, "W":6}
Zauważysz, że przechowuję obiekty typu A tuż obok obiektów typu B. MongoDB bardzo to ułatwia. Po prostu wyciągnij dokument z Kolekcji, który "magicznie" ma wszystkie odpowiednie pola/właściwości.
Jeśli jednak masz „obiekty danych” lub „encje”, możesz ułatwić sobie życie, dodając typ.
{"_id":"1", "type":"A", "X":1, "Y":2, "Z":3}
{"_id":"2", "type":"B", "X":5, "Y":6, "Z":7, "W":6}
Ułatwia to napisanie klasy fabrycznej do ładowania obiektów.
