MasterOfTheBus / Crescendo

A website to track piano progress
0 stars 0 forks source link

Create a schema for Book and wire the relationships for other schemas (Exercises, Books) #9

Open chubchubcharles opened 7 years ago

chubchubcharles commented 7 years ago

Why Book? In our Exercise schema, we should make Books a schema instead of just a field. How I decide if something should be a schema or just remain a field is whether there is a need to ever CRUD on Books. I feel like this could be necessary, if in the future someone wanted to add a book and all the exercises related to a book could be reproduced (maybe because someone else has already manually inserted all the exercises for a book).

Task Description

Exit Criteria

Edits The scope of work for modifying users has moved to another issue

chubchubcharles commented 7 years ago

Regarding how to associate User and Exercise models:

I first read Data Modeling Introduction to learn that in MongoDB the key decision to figuring out between mapping relationships between entities is whether to go with: references or embedded documents.

I wanted to understand the advantages and disadvantages of using references and embedded documents here and here.

Before I talk about the User and Exercise, I can confidently answer that for Exercises and Book in our later decision, we should use references instead of embedded documents. It mirrors the analogy here with Books and a common Publisher.

For User and Exercise, I think we should use embedded documents because for each User, which has many exercises, we will regularly query the User first, and then upon that peruse over the Exercises it has completed/"needs learning"/etc.

What do you think?

MasterOfTheBus commented 7 years ago

I agree with the structure, makes sense when we add the progression for individual exercises for a user.

in terms of the scope of the work, I'm going to split this task up into creating a schema for books and modifying the schema for users