So I was wondering, the one downside I have to NoSQL is: if my front end app ever drastically changes then I would have a horrible time remodeling my database. This is because NoSQL is designed with front end in mind first. So if front end changes, back end changes (at least that is the general idea)
So my idea is, would it be smart to store all my ORIGINAL/PURE copies of documents in multiple root collections. And then create "views" collections which are the collections my app will call. What I like about this is that my data is always "SQL" at root if I ever need to change my front end. But my "views" are actually what my app will use.
This is a lot like the dimension/reference table and fact table design people use.
The big reason once again for this idea: if my front end changes drastically, then I need to do serious work converting these "views" to other "views". Where with my idea, you would just delete your old "views" and create new "views" using your "sql"/"root" reference tables.
Do I make sense? :) I have not used NoSQL (but I am building something now with it so my brain is still battling with SQL to NoSQL haha). So if this is a "dude don't worry about it case" then you can give that as an answer as well haha
Yup, that is indeed a fairly common approach. I recent answers about NoSQL data modeling I started calling this out explicitly:
With these two in mind, fanning out/duplicating the data is a fairly straightforward process (literally: as it's unidirectional), and can easily be redone by wiping the derived data and rerunning the fan-out process.
Some good pointers to learn more about NoSQL data modeling:
And these previous questions: