title: Mongodb design pattern - the trade off between memory vs disk space
body: <p>I am new to mongodb and have been doing some digging on NoSQL design patterns, but have been a bit confused on a scenario. I can implement this concept in SQL a number of ways, but am unsure about achieving this with NoSQL.</p>
  
  <p>The reasons for exploring a NoSQL solution are: <br/>
  1) Simply, the sake of learning something new</p>
  
  <p><strong>Scenario:</strong> 
  Say we have a list of movie titles, and a list of users. Each user receives a feed of new movie titles. Once the movie is presented to the user, the user must like or dislike the movie. Once they vote (either like or dislike), the movies will never be presented to that user again, thus curating their new movies list. </p>
  
  <p>So just to recap <br/>
  1) The new movies list will always display movies that have never been previously presented to this user. <br/>
  2) We would need to query for a list of the users 'liked' movies.
  <br/><br/>
  In SQLServer this is extremely straight forward and simple, we have three tables (Users, Movies, Votes) with relationships established with each of the Ids</p>
  
  <pre><code>User{
       int UserId, 
       varchar UserName
      }
  Movie{
       int MovieId,
       varchar MovieTitle,
       varchar MovieDescription
  }
  Vote{
       int VoteId,
       int UserId,
       int MovieId,
       bit DidUserLikeMovie
  }
  </code></pre>
  
  <ul>
  <li>Every time a user votes, we can add their vote to the Votes table <br/></li>
  <li>Every time we need a list of the users 'liked' movies we can easily join the tables and receive a list<br/></li>
  <li>Every time we need a list of new movies we can just verify that the userId has no entry on the vote table for the requested movieId</li>
  </ul>
  
  <p><strong>Question:</strong>
  Now my question is, in a NoSQL environment, what would be the proper design approach?</p>
  
  <p><strong>My Thoughts:</strong> <br/>
  <strong>1)</strong> We could design the setup the same way with the three tables (Users, Movies, and Votes), however this would require an ample amount of reads every time a user requested a new movieList since NoSQL doesn't have joins or relationships. <br/>
  <strong>2)</strong> We could design the setup with two documents (Users, Movies) and store the votes within the Movies document as so:</p>
  
  <pre><code>Movies{
           int MovieId,
           varchar MovieTitle,
           varchar MovieDescription
           List&lt;Votes&gt; Votes {
                        User UserInfo {...},
                        bool DidUserLikeMovie,
                  }
      }
  </code></pre>
  
  <p>This could be a bit expensive when we want to get a list of movies that the user has already 'liked' <br/>
  <strong>3)</strong> We could store the movie votes in the user document</p>
  
  <pre><code>User{
           int UserId, 
           varchar UserName
           List&lt;Votes&gt; Votes {
                        Movie MovieInfo { ... },
                        bool DidUserLikeMovie,
                  }
      }
  </code></pre>
  
  <p>But this could be a bit expensive to generate our list of new movies <br/>
  <strong>4)</strong> We could use a hybrid of the described approaches and store the votes both in the Movie document and in the User Document. This would result in quick reads however this would require writes to both the Movie Document, and User Document and would require the database to grow twice as fast. <br/></p>
  
  <p>Any advice, articles, or additional options are greatly appreciated!</p>