Surpris, la plupart des réponses semblent avoir manqué la question, mais je vais essayer ;
C'est ce qu'on appelle la modélisation des données (comment vous enchaînez un tas de tables dans une base de données afin d'exprimer ce que vous voulez de la meilleure façon possible), et ne vous sentez pas idiot de demander ; il y a des gens qui passent toutes leurs heures à peaufiner et à concevoir des modèles de données. Ils sont extrêmement importants pour le bien-être de tout système, et ils sont, en vérité, bien plus importants que la plupart des gens ne le pensent.
Il semble que vous soyez sur la bonne voie. C'est toujours un bon conseil de définir vos entités et de créer une table pour chacune, donc dans ce cas, vous avez des utilisateurs, des listes de lecture et des chansons (par exemple). Définissez vos tableaux ainsi; UTILISATEUR, CHANSON, LISTE DE LECTURE.
La prochaine chose est de définir les noms des champs et des tables (et peut-être que les noms simplistes suggérés ci-dessus sont, eh bien, simplistes). Certains introduisent de faux espaces de noms (c'est-à-dire MYAPP_USER au lieu de simplement USER), surtout s'ils savent que le modèle de données s'étendra et se développera dans la même base de données à l'avenir (ou, certains parce qu'ils savent que c'est inévitable), tandis que d'autres vont juste traverser tout ce dont ils ont besoin.
La grande question portera toujours sur la normalisation et divers problèmes autour de cela, équilibrer les performances par rapport à l'applicabilité, et il y a des tonnes et des tonnes de livres écrits sur ce sujet, donc je ne peux pas vous donner de réponse significative, mais l'essentiel pour moi est :
À quel moment un champ de données dans une table sera-t-il digne de sa propre table ? Un exemple est que vous pourriez très bien créer votre application avec une seule table, ou deux, ou 6 selon la façon dont vous souhaitez diviser vos données. C'est là que je pense que votre question entre vraiment en jeu.
Je dirais que vous avez à peu près raison dans vos hypothèses, la chose à garder à l'esprit est la cohérence des conventions de dénomination (et il y a des tonnes d'opinions sur la façon de nommer les identifiants). Pour votre application (avec les tableaux mentionnés ci-dessus), je ferais;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Maintenant, vous pouvez utiliser SQL pour obtenir toutes les listes de lecture d'un utilisateur ;
SELECT * FROM PLAYLIST WHERE userid=$userid
Ou obtenez toutes les chansons dans une liste de lecture ;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
Etc. Encore une fois, des tomes ont été écrits sur ce sujet. Il s'agit de penser clairement et sémantiquement tout en notant une solution technique. Et certaines personnes n'ont que cela comme carrière (comme les DBA). Il y aura beaucoup d'opinions, surtout sur ce que j'ai écrit ici. Bonne chance.
