Si tes préférences sonores sont le volume, les basses, mediums, aigüs, la piste préférée etc. alors un champ pour chaque info dans une table suffira bien.
Si par contre tu voulais enregistrer pour chaque piste musicale son propre volume, equalizer, alors pourquoi pas stocker ton tableau imbriqué dans une base clé/valeur. ça marcherait très bien avec une seule table en sgbdr avec les mêmes champs que précédemment mais une clé primaire sur deux champs : joueur et piste.
Si tu veux faire des stats dessus ou faire plein de traitement concernant plusieurs joueurs à la fois, pourquoi ne pas utiliser un SGBDR en effet. Surtout si le reste de ton appli l'utilise déjà.
Mais, comme le son c'est côté client, ça sera probablement traité en javascript. donc stocker toutes ces préférences (je parle toujours pour chaque piste séparément, donc un objet assez dense) dans un objet javascript sera une étape forcée. Le meilleur moyen de stocker ça sur le serveur sera probablement d'envoyer cet objet au serveur au format JSON. Et là, avec une base noSQL il te suffit simplement de stocker le JSON dans une base clé/valeur. En clé l'ID du joueur et en valeur le JSON. Pas besoin de code serveur pour lire le JSON, d'une structure de données côté serveur et de mettre ça en requête SQL ou d'utiliser un ORM, tu le stockes, point barre. Et en contrepartie pour faire tes stats il te faudra faire un peu de code.
Et enfin, perso je n'aurai jamais la même config selon mon PC : mon laptop sera au casque ou à la chaine hi-fi, donc sur celui-ci il faudrait balancer la sauce. Sur mon mobile, pas de son. Sur mon PC de bureau, des baffles pas terribles ou le casque donc selon le cas je devrai changer régulièrement, et enfin au boulot pas de son. Donc dans ce cas, stocker l'objet javascript directement dans le localStorage du navigateur me paraît la meilleure option, et ça ce n'est pas un SGBDR.
Si par contre tu voulais enregistrer pour chaque piste musicale son propre volume, equalizer, alors pourquoi pas stocker ton tableau imbriqué dans une base clé/valeur. ça marcherait très bien avec une seule table en sgbdr avec les mêmes champs que précédemment mais une clé primaire sur deux champs : joueur et piste.
Si tu veux faire des stats dessus ou faire plein de traitement concernant plusieurs joueurs à la fois, pourquoi ne pas utiliser un SGBDR en effet. Surtout si le reste de ton appli l'utilise déjà.
Mais, comme le son c'est côté client, ça sera probablement traité en javascript. donc stocker toutes ces préférences (je parle toujours pour chaque piste séparément, donc un objet assez dense) dans un objet javascript sera une étape forcée. Le meilleur moyen de stocker ça sur le serveur sera probablement d'envoyer cet objet au serveur au format JSON. Et là, avec une base noSQL il te suffit simplement de stocker le JSON dans une base clé/valeur. En clé l'ID du joueur et en valeur le JSON. Pas besoin de code serveur pour lire le JSON, d'une structure de données côté serveur et de mettre ça en requête SQL ou d'utiliser un ORM, tu le stockes, point barre. Et en contrepartie pour faire tes stats il te faudra faire un peu de code.
Et enfin, perso je n'aurai jamais la même config selon mon PC : mon laptop sera au casque ou à la chaine hi-fi, donc sur celui-ci il faudrait balancer la sauce. Sur mon mobile, pas de son. Sur mon PC de bureau, des baffles pas terribles ou le casque donc selon le cas je devrai changer régulièrement, et enfin au boulot pas de son. Donc dans ce cas, stocker l'objet javascript directement dans le localStorage du navigateur me paraît la meilleure option, et ça ce n'est pas un SGBDR.