Zaskoczony, wydaje się, że większość odpowiedzi pominęła pytanie, ale spróbuję;
Nazywa się to modelowaniem danych (jak kuśtykasz razem kilka tabel w bazie danych, aby wyrazić to, czego chcesz w najlepszy możliwy sposób) i nie czujesz się głupio, gdy pytasz; są ludzie, którzy spędzają całe godziny na ulepszaniu i projektowaniu modeli danych. Są ogromnie ważne dla dobrego samopoczucia każdego systemu i tak naprawdę są o wiele ważniejsze, że większość ludzi je docenia.
Wygląda na to, że jesteś na właściwej ścieżce. Zawsze dobrze jest zdefiniować swoje jednostki i utworzyć tabelę dla każdej z nich, więc w tym przypadku masz użytkowników, listy odtwarzania i utwory (na przykład). W ten sposób zdefiniuj swoje tabele; UŻYTKOWNIK, UTWÓR, LISTA ODTWARZANIA.
Następną rzeczą jest zdefiniowanie nazw pól i tabel (i być może uproszczone nazwy sugerowane powyżej są, no cóż, uproszczone). Niektórzy wprowadzają fałszywe przestrzenie nazw (np. MYAPP_USER zamiast tylko USER), zwłaszcza jeśli wiedzą, że model danych będzie się rozszerzał i rozszerzał w tej samej bazie danych w przyszłości (lub niektórzy, ponieważ wiedzą, że jest to nieuniknione), podczas gdy inni po prostu przebijają się czego potrzebują.
Wielkie pytanie zawsze będzie dotyczyć normalizacji i różne problemy z tym związane, równoważenie wydajności z możliwością zastosowania, i jest mnóstwo książek napisanych na ten temat, więc nie mogę udzielić żadnej sensownej odpowiedzi, ale sedno tego jest dla mnie;
W którym momencie pole danych w tabeli będzie godne własnej tabeli? Przykładem jest to, że możesz stworzyć swoją aplikację z tylko jedną tabelą, dwiema lub 6 tabelami, w zależności od tego, jak chcesz podzielić dane. Myślę, że w tym miejscu naprawdę pojawia się Twoje pytanie.
Powiedziałbym, że masz rację w swoich założeniach, należy pamiętać o spójnych konwencjach nazewnictwa (i jest mnóstwo opinii na temat nazywania identyfikatorów). Dla twojej aplikacji (z tabelami wymienionymi powyżej) zrobiłbym;
USER { id, username, password, name, coffee_preference }
SONG { id, artist, album, title, genre }
PLAYLIST { id, userid }
PLAYLIST_ITEM { id, songid, playlistid, songorder }
Teraz możesz używać SQL, aby uzyskać wszystkie listy odtwarzania dla użytkownika;
SELECT * FROM PLAYLIST WHERE userid=$userid
Lub zdobądź wszystkie utwory na liście odtwarzania;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
I tak dalej. Znowu na ten temat napisano tomy. Wszystko sprowadza się do jasnego i semantycznego myślenia podczas zapisywania technicznego rozwiązania. A niektórzy ludzie mają tylko taką karierę (jak DBA). Będzie wiele opinii, zwłaszcza na temat tego, co tu napisałem. Powodzenia.
