Schema/API Design Comments, Vaughn Rostermundt

[vrosterm]

• TRACKS shouldn't need a track_id and a primary key id.
• Should there also be an ALBUMS table?
• There's nothing here relating to a vector for recommendations. While I understand its purpose, its literal use is a bit vague within the endpoints.
• SEARCH HISTORY needs to reference TRACKS somewhere
• RECOMMENDATION HISTORY needs to reference TRACKS somewhere
• RATINGS is good for one user, but what happens if there are multiple? Do we need multiple RATINGS tables?
• In reference to above, USER RATINGS may be a good option for a particular user's tastes.
• How exactly are recommendations given out? Is there a master list for tracks?
• Unsure if tracks, playlists, or playlist_tracks need a timestamp column.
• No API spec for returning playlists, or histories of any kind. I feel like this is incomplete.
• Should Searching the music system also return a rating, if given?
• It may be good to give the likeliness of enjoyment (aka the vector thing) to the user in their recs.
• Again, no endpoints return the list of songs within a playlist: just the ID.
• Entering nothing into the query parameters causes the program to hang forever.