Sorprendido, la mayoría de las respuestas parecen haber pasado por alto la pregunta, pero lo intentaré;
Esto se llama modelado de datos (cómo junta un montón de tablas en una base de datos para expresar lo que quiere de la mejor manera posible), y no se sienta tonto por preguntar; hay personas que pasan todas sus horas de vigilia ajustando y diseñando modelos de datos. Son enormemente importantes para el bienestar de cualquier sistema y, en verdad, son mucho más importantes de lo que la mayoría de la gente cree.
Parece que estás en el camino correcto. Siempre es un buen consejo definir sus entidades y crear una tabla para cada una, de modo que en este caso tenga usuarios, listas de reproducción y canciones (por ejemplo). Defina sus tablas así; USUARIO, CANCIÓN, LISTA DE REPRODUCCIÓN.
Lo siguiente es definir los nombres de los campos y las tablas (y tal vez los nombres simplistas sugeridos anteriormente sean, bueno, simplistas). Algunos introducen espacios de nombres falsos (es decir, MYAPP_USER en lugar de solo USER), especialmente si saben que el modelo de datos se extenderá y expandirá en la misma base de datos en el futuro (o, algunos porque saben que esto es inevitable), mientras que otros simplemente lo harán. lo que necesiten.
La gran pregunta siempre será sobre normalización y varios problemas en torno a eso, equilibrar el rendimiento con la aplicabilidad, y hay toneladas y toneladas de libros escritos sobre este tema, por lo que no tengo forma de darle una respuesta significativa, pero la esencia de esto para mí es:
¿En qué punto un campo de datos en una tabla será digno de su propia tabla? Un ejemplo es que bien podría crear su aplicación con solo una tabla, o dos, o 6 dependiendo de cómo desee dividir sus datos. Aquí es donde creo que realmente entra tu pregunta.
Diría que tiene bastante razón en sus suposiciones, lo que debe tener en cuenta son las convenciones de nomenclatura consistentes (y hay toneladas de opiniones sobre cómo nombrar identificadores). Para su aplicación (con las tablas mencionadas anteriormente), haría;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Ahora puede usar SQL para obtener todas las listas de reproducción de un usuario;
SELECT * FROM PLAYLIST WHERE userid=$userid
O consigue todas las canciones en una lista de reproducción;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
Y así. Nuevamente, se han escrito tomos sobre este tema. Se trata de pensar con claridad y semánticamente mientras se apunta una solución técnica. Y algunas personas solo tienen esto como carrera (como los DBA). Habrá muchas opiniones, especialmente sobre lo que he escrito aquí. Buena suerte.
