title: Firebase: Is it a good idea to use dimension / fact table design in NoSQL
body: <p>So I was wondering, the one downside I have to NoSQL is: <strong>if my front end app ever drastically changes then I would have a horrible time remodeling my database</strong>. 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)</p>
  
  <p>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.</p>
  
  <p>This is a lot like the dimension/reference table and fact table design people use.</p>
  
  <p>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.</p>
  
  <p>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</p>