Surpreendentemente, a maioria das respostas parece ter perdido a pergunta, mas vou tentar;
Isso é chamado de modelagem de dados (como você junta um monte de tabelas em um banco de dados para expressar o que você quer da melhor maneira possível), e não se sinta bobo por perguntar; há pessoas por aí que passam todas as suas horas de vigília ajustando e projetando modelos de dados. Eles são extremamente importantes para o bem-estar de qualquer sistema e, na verdade, são muito mais importantes do que a maioria das pessoas lhes dá crédito.
Parece que você está no caminho certo. É sempre uma boa dica definir suas entidades, e criar uma tabela para cada uma, então neste caso você tem usuários e playlists e músicas (por exemplo). Defina suas tabelas assim; USUÁRIO, MÚSICA, PLAYLIST.
A próxima coisa é definir os nomes dos campos e tabelas (e talvez os nomes simplistas sugeridos acima sejam, bem, simplistas). Alguns introduzem namespaces falsos (ou seja, MYAPP_USER em vez de apenas USER), especialmente se eles souberem que o modelo de dados será estendido e expandido no mesmo banco de dados no futuro (ou alguns porque sabem que isso é inevitável), enquanto outros apenas passarão por tudo o que eles precisam.
A grande questão sempre será sobre a normalização e vários problemas em torno disso, equilibrando desempenho contra aplicabilidade, e há toneladas e toneladas de livros escritos sobre esse assunto, então não há como eu lhe dar uma resposta significativa, mas a essência disso para mim é;
Em que ponto um campo de dados em uma tabela será digno de sua própria tabela? Um exemplo é que você poderia criar seu aplicativo com apenas uma tabela, ou duas, ou 6, dependendo de como deseja dividir seus dados. É aqui que eu acho que sua pergunta realmente entra.
Eu diria que você está bastante correto em suas suposições, o que deve ser lembrado são as convenções de nomenclatura consistentes (e há muitas opiniões sobre como nomear identificadores). Para sua aplicação (com as tabelas mencionadas acima), eu faria;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Agora você pode usar o SQL para obter todas as listas de reprodução de um usuário;
SELECT * FROM PLAYLIST WHERE userid=$userid
Ou obtenha todas as músicas em uma lista de reprodução;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
E assim por diante. Novamente, tomos foram escritos sobre este assunto. É tudo uma questão de pensar de forma clara e semântica enquanto anota uma solução técnica para isso. E algumas pessoas têm apenas isso como carreira (como DBA's). Haverá muitas opiniões, especialmente sobre o que escrevi aqui. Boa sorte.
