Verbaasd lijken de meeste antwoorden de vraag te hebben gemist, maar ik zal dit eens proberen;
Dit wordt datamodellering genoemd (hoe je een heleboel tabellen in een database door elkaar husselt om op de best mogelijke manier uit te drukken wat je wilt), en je hoeft je niet dom te voelen om te vragen; er zijn mensen die al hun wakkere uren besteden aan het tweaken en ontwerpen van datamodellen. Ze zijn enorm belangrijk voor het welzijn van elk systeem, en ze zijn in werkelijkheid veel belangrijker dan de meeste mensen ze toeschrijven.
Het klinkt alsof je op de goede weg bent. Het is altijd een goede tip om je entiteiten te definiëren en voor elk een tabel te maken, dus in dit geval heb je gebruikers en afspeellijsten en nummers (bijvoorbeeld). Definieer uw tabellen zo; GEBRUIKER, LIED, AFSPEELLIJST.
Het volgende ding is het definiëren van de namen van velden en tabellen (en misschien zijn de simplistische namen die hierboven worden gesuggereerd, nou ja, simplistisch). Sommigen introduceren valse naamruimten (dwz MYAPP_USER in plaats van alleen USER), vooral als ze weten dat het datamodel in de toekomst zal uitbreiden en uitbreiden in dezelfde database (of, sommigen omdat ze weten dat dit onvermijdelijk is), terwijl anderen er gewoon doorheen rammen wat ze ook nodig hebben.
De grote vraag zal altijd gaan over normalisatie en verschillende problemen daaromheen, het balanceren van prestaties en toepasbaarheid, en er zijn tonnen en tonnen boeken geschreven over dit onderwerp, dus ik kan je geen zinnig antwoord geven, maar de kern ervan is voor mij;
Op welk punt zal een gegevensveld in een tabel zijn eigen tabel waardig zijn? Een voorbeeld is dat u uw toepassing heel goed kunt maken met slechts één tabel, of twee, of 6, afhankelijk van hoe u uw gegevens wilt splitsen. Dit is waar ik denk dat je vraag echt van pas komt.
Ik zou zeggen dat je vrijwel gelijk hebt in je aannames, het ding om in gedachten te houden zijn consistente naamgevingsconventies (en er zijn talloze meningen over hoe je identifiers een naam geeft). Voor uw toepassing (met de hierboven genoemde tabellen), zou ik doen;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Nu kun je SQL gebruiken, je krijgt alle afspeellijsten voor een gebruiker;
SELECT * FROM PLAYLIST WHERE userid=$userid
Of haal alle nummers in een afspeellijst;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
Enzovoort. Opnieuw zijn er boekdelen over dit onderwerp geschreven. Het draait allemaal om helder en semantisch denken terwijl je er een technische oplossing voor opschrijft. En sommige mensen hebben alleen dit als een carrière (zoals DBA's). Er zullen veel meningen zijn, vooral over wat ik hier heb geschreven. Veel succes.