justinchore / Record-Press

0 stars 0 forks source link

Design doc review #1 #1

Open aracpyon opened 4 years ago

aracpyon commented 4 years ago

Hi Justin, Great job so far! Here is my review:

MVP

Schema Auth

justinchore commented 4 years ago

Hi Ara, thank you for the feedback! After implementing some of the changes, I can already see my plans becoming more streamlined and straightforward. Just a few questions:

  1. About "you don't need artist_id because it belongs to album and album has artist_id" (box 5). I find that many artists on bandcamp upload single tracks as opposed to albums. Is having artist_id in tracks still not the right move?

  2. I'm having trouble conceptualizing the genre joins table. Would I be making one genres table to handle all of the different genres? Columns being: id, genre_name, user_id, album_id, track_id. Optional columns being user_id, album_id, track_id because a "rock" artist might release a "rap" album. Maybe I'm just over-thinking this?

  3. "add a name column to wishlists" (last box) Why does a wishlist need a name?

Thank you very much for your help! I know it's a lot of work helping everyone out on their projects.

aracpyon commented 4 years ago

Hey Justin, here are my relies to your questions:

  1. Yeah, you are right. I didn't know there will be a single track without album. In that case, let's add artist_id to Tracks and also add album_id to Tracks it will be optional.

  2. Genres table has only id, name | id | name | created_at | updated_at | | 1 | rock. | | 2 | rap | | 3 | kpop | | 4 | jazz |

Polymorphic genre's join table is just like Likes table that can be belongs to both Comments and Posts (Likes is not a joins table. It's just polymorphic). It has a user_id and likeable-id andlikeable-type. In your case, genre-joins table should not only be a polymorphic table but also joins table. If you don't use polymorphic joins table, you probably should make three different joins tables between genre and each of artist, track, album such as... user-genres table id | genre_id | user_id |. created_at | updated_at 1 |. 1. |. 2 2 |. 2 |. 2

  1. |. 3. |. 2
  2. |. 2. |. 3

album-genres table id | genre_id | album_id |. created_at | updated_at 1 |. 1. |. 5 2 |. 2 |. 4

  1. |. 3. |. 5
  2. |. 2. |. 4

track-genres table id | genre_id | album_id |. created_at | updated_at 1 |. 1. |. 2 2 |. 2 |. 1

  1. |. 3. |. 1
  2. |. 2. |. 1

However, it will be little redundant to make three different tables for each type of entities with Genres so therefore, you are adopting polymorphic relationship here. genre-joins (you can name it differently) id | genre_id | genreable-id |. genreable-type | created_at | updated_at 1 |. 1. |. 1 |. User | 2 |. 2 |. 1 | Album

  1. |. 3. |. 5 | Track

  2. |. 2. |. 1 | User

  3. User can make a many wishlists. Such as favorite, buy-soon etc. If User can make only one wishlist per User, then never mind. But probably you should still make a joins table(track-wishlist) between Track and Wishlist because track can have many wishlists and wishlist can have many tracks. update: I just found Album has many wishlists too! Then probably you need to make Wishlist as polymorphic. (If User can only make one wishlist, it will be just polymorphic, not polymorphic joins)

Hope this make sense!