Schema/API Design comments Jenna Chan

[jenchan88]

1. Implement pagination parameters (offset, limit) in the /search endpoint to handle large result sets efficiently.
2. Consider making track_id the primary key in the tracks table if it uniquely identifies tracks across your system.
3. Add indexes to columns that serve as foreign keys (user_id, playlist_id, track_id) to improve query performance.
4. Define appropriate constraints such as NOT NULL for mandatory fields like username in the users table.
5. Use consistent data types for IDs (SERIAL or INTEGER) across all tables for clarity and consistency.
6. Apply unique constraints where appropriate, such as on username in the users table to enforce uniqueness.
7. Ensure API endpoints are defined for retrieving playlists and histories (search history, recommendation history) as specified in your API documentation.
8. Validate query parameters (e.g., track, album, artist) in the /search endpoint to handle invalid input gracefully.
9. If search_history is meant to log searches related to tracks, associating it with tracks could provide context and possibly enable features like search analytics based on specific tracks
10. There appears to be the creation of two playlist_tracks tables.
11. If ratings are stored, consider including them in search results to provide users with more information about tracks.
12. Handle cases where query parameters are empty gracefully in your API endpoints to prevent issues like hanging or excessive resource consumption.
13. Similar to search history, recommendation history should ideally reference tracks to indicate which tracks were recommended to users at specific times.