La maggior parte delle risposte sorprese sembra aver perso la domanda, ma ci proverò;
Questo si chiama modellazione dei dati (come zoppicare un mucchio di tabelle in un database insieme per esprimere ciò che vuoi nel miglior modo possibile) e non sentirti stupido a chiedere; ci sono persone là fuori che passano tutte le loro ore di veglia a modificare e progettare modelli di dati. Sono estremamente importanti per il benessere di qualsiasi sistema e, in verità, sono molto più importanti per cui la maggior parte delle persone li riconosce.
Sembra che tu sia sulla strada giusta. È sempre un buon consiglio definire le tue entità e creare una tabella per ciascuna, quindi in questo caso hai utenti, playlist e brani (ad esempio). Definisci così le tue tabelle; UTENTE, BRANO, PLAYLIST.
La prossima cosa è definire i nomi di campi e tabelle (e forse i nomi semplicistici suggeriti sopra sono, beh, semplicistici). Alcuni introducono falsi spazi dei nomi (ad es. MYAPP_USER invece del solo USER), soprattutto se sanno che il modello di dati si estenderà e si espanderà nello stesso database in futuro (o, alcuni perché sanno che è inevitabile), mentre altri si limitano a scorrere tutto ciò di cui hanno bisogno.
La grande domanda riguarderà sempre la normalizzazione e vari problemi al riguardo, bilanciando le prestazioni con l'applicabilità, e ci sono tonnellate e tonnellate di libri scritti su questo argomento, quindi non c'è modo per me di darti una risposta significativa, ma per me il succo è;
A che punto un campo dati in una tabella sarà degno della propria tabella? Un esempio è che potresti creare la tua applicazione con una sola tabella, o due, o 6 a seconda di come desideri dividere i tuoi dati. È qui che penso che la tua domanda entri davvero in gioco.
Direi che hai praticamente ragione nelle tue ipotesi, la cosa da tenere a mente sono le convenzioni di denominazione coerenti (e ci sono tonnellate di opinioni su come nominare gli identificatori). Per la tua applicazione (con le tabelle sopra menzionate), lo farei;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Ora puoi usare SQL per ottenere tutte le playlist per un utente;
SELECT * FROM PLAYLIST WHERE userid=$userid
Oppure ottieni tutti i brani in una playlist;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
E così via. Anche in questo caso, sono stati scritti dei tomi su questo argomento. Si tratta di pensare in modo chiaro e semantico mentre si annota una soluzione tecnica. E alcune persone hanno solo questo come carriera (come quella di DBA). Ci saranno molte opinioni, soprattutto su ciò che ho scritto qui. Buona fortuna.
