zalezi od aplikacie, ked to je priamociara vec a la IoT kde skoro stale len zapisujem a obcas precitam a viem co robim a aky to ma usecase tak to nie je problem ale vyhoda - dostanem za to nieco ine (nechcem ist tym smerom, ze co, nechcem o tom tu pisat).
ked ale mam nejaku skladovu aplikaciu kde "ani boh" nevie ako sa tie data / schema bude casom menit tak normalne sql tam samozrejme ma vacsiu vyhodu.
osobne som zazil nosql projekt netrivialnej velkosti a po tom ako sa nastavila schema tak sa uz menila len minimalne - len sa pridavali fieldy a tabulky nad tym logika spravila vsetko. nehovorim ze to bolo lahke a ze sme vela krat lutovali ze to nema joiny ale je to proste iny svet a treba sa na to pozerat inak.
aby som bol uplne presny tak my sme velmi neduplikovali pretoze to so sebou prinasa tiez nevyhody - napr. Cassandra ma batch statements ktore simuluju lightweight transakcie a je to trosku narocnejsie na koordinatora ale ked sa to neznasilnuje, tak sa to da pouzit.
za tym nazorom "tabulku si navrhnem podla query" si stojim - stoji na tom cela filozofia Cassandry a ma to velmi silne vyhody ked clovek vie co robi. "schema na query" nie je moj vymysel, staci si o tom nieco precitat - vela ludi je toho zastancom.