Itt megint az a problema hogy ugy gondolsz a noSql jellegu megoldasra mint amit egy az egyben replacement jelleggel bedobsz egy relational model helyere, pedig ez nem igy van. Azert hivjak a (bizonyos) noSql megoldasokat aggregate store-oknak is masneven (ddd) mert egy aggregate az egy "consistency boundary" minek amivel konzisztensnek kell lennie az bennevan ebben a boundaryben (keyben, documentben), nem lehet olyan amivel konzisztensnek kell lennie es nincs benne, ha van, akkor benne kellene lennie, es maga a design rossz, amin valtoztatni kell. Egy rosz, nem illeszkedo designra nem tudsz jol mukodo rendszert csinalni, semmilyen technologia megoldas, legyen az noSql vagy barmi egyeb nem fogja megoldani az ilyen jellegu problemaidat. Semmilyen technologiai megoldas nem "silver bullet", es nem alkalmazhato mindenre. (Szoval igen, nem kell joinolni)
Azonban ravilagitottal az egyik tipikusan felhozott dologra ami szinte tankonyvbe illo mikor noSql megoldasokat (foleg key) magyaraznak el, es ez az hogy ezek a megoldasok tipikusan nem tamogatjak azt hogy konnyeden atrstukturald az adatokat olyan formara amilyenre szeretned allandoan. Gondolok it reportingra. Ezert szokott reporting celokra vagy parhuzamosan lenni egy relacios model is (mivel igazan forgalmas helyen live dbt azert nem live reportolunk), vagy van valamilyen asszikron process a hatterben ami ezeket meggyotri es kiszedi beloluk naponta egyszer mondjuk azt ami reportinghoz kell. Mig altalnossagban egy relacios model kicsit univerzalisabb es kepes ellatni sokfele funkciot valtozo eredmenyesseggel es teljesitmennyel, addig tipikusn a noSql megoldasok joval specializalodottabbak es egy szukebb felhasznalasi korben nyujtanak sokkal jobb teljesitmenyt mig mas celokra kenyelmetlen a hasznalatuk. megintcsak, attol fugg mire van szukseged.
Egyszeruen a gondolkodasmod teljesen mas.