Discussion :

[agent007se]

Bonjour à tous,

Je suis en train de faire un petit programme qui liste des fichiers musicaux.
J'aimerais en fait savoir si ma façon de voir la base de donnée est correcte...

Voici ce que quelqu'un m'a conseillé...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Playlists_T // table qui contient une liste de tables Playlist_T
    Playlists
        pls_1
        pls_i
        pls_n
 
Playlist_T // table qui contient une liste de ID de musiques
    musicID
        mID_1
        mID_i
        mID_n
 
ListMusic_T // table qui contient les ID, les noms de fichiers ainsi que les chemins d'accès
    ID        musicFileName        path
        ID_1        fileName_1        path_1
        ID_i        fileName_i        path_i
        ID_n        fileName_n        path_n
 
Music_T // une table Music_T par fichier musique...
    Title        Artist            Year            etc
        titre_1        artiste_1        year _1        etc

Le GROS problème c'est bien sur la dernière table. En effet, dans le cas extrême d'une personne qui possède, disons, 10.000 fichiers je crois que ça poserait un sacré problème de performances...

Maintenant, la version que je propose et qui, si elle est juste, ne vous demandera qu'un "FONCE" .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
Playlists_T // table qui contient une liste de tables Playlist_T
    Playlists
        pls_1
        pls_i
        pls_n
 
Playlist_T // table qui représente une playlist
    musicID    musicFileName      path        Title          Artist        Year        etc
      mID_1      fileName_1         path_1      titre_1       artiste_1     year_1      etc_1
      mID_i      fileName_i         path_i      titre_i       artiste_i     year_i      etc_1
      mID_n      fileName_n         path_n      titre_n       artiste_n     year_n      etc_n

D'avance, merci (ça fait deux jours que je réfléchis :p).

Je tiens à préciser que, avant de répondre, il faut bien être conscient que ce ne sont pas des playlists au sens commun du terme (glisser déposer dans winamp et ça play). Ce sont plus des listes "tout court" (fallait bien leur donner un nom) qui n'ont, en aucun cas, pour but d'être des playlists.

[neuropathie]

il n y a pas une seule façon pour concevoir ta base de données, mais je préfére de loin ta deuxième proposition.

[agent007se]

Je sais qu'il peut y avoir plusieurs solutions et certainement meilleures que la mienne (la seconde).

Cependant, il faut savoir qu'il y a encore deux jours je savais pas ce que c'était un "select * from maTable" :p.

Donc je pense d'abord commencer petit puis, au pire, tout refaire "from scratch" si ça en vaut la peine.

Petite question supplémentaire :
Au sujet des ID ... sachant que je compte parcourir parfois des dossiers mais que leur contenu va changer, comment donner des ID aux fichiers ? (de 1 à n ?) aléatoirement (à mon avis sûrement pas mais bon) ?

Le top du top ce serait de générer un ID unique de 5 ou 6 chiffres. Je pense à un ID basé sur le nom du fichier + le chemin du fichier. Je sais que ça dépasse le langage SQL (y'a bien une fonction pour check qu'on a pas deux fois la même entrée je crois par exemple je pourrais l'appliquer à la colonne "path" mais je CROIS (à confirmer par vous donc :p) que ça pompe pas mal de ressources non ?

1) Mieux vaut trouver un moyen de générer un ID unique ? (comment)
2) Mieux vaut laisser SQL s'occuper de ça en lui imposant qu'il ne peut pas y avoir deux fois le même chemin dans la colonne path ?

En tous cas déjà merci pour ta réponse !

Deuxième petite question supplémentaire :
Je compte supprimer la colonne musicFileName... quelqu'un y voit une objection ? En fait je me dis que cette colonne ne sert à rien vu qu'à partir du moment où on a le chemin entier et absolu... il n'y a aucun problème pour retirer le nom du fichier (et encore moins avec Qt :p)

[yizashi]

Voilà ce que je ferais:
Table "auteur":
id, nom, prenom, etc.

Table "fichier":
id, nom, chemin, dateModification

Table "genre":
id, libelle

Table "enregistrement"
id, titre, annee, idFichier, idAuteur, idGenre

Table "listeEnregistrements"
id, numero, idEnregistrement

Tous les "id" sont auto-incrémentés bien sûr, tu n'auras donc pas à les gérer si tu utilises une base de données correcte. Concernant le chemin absolu du fichier au lieu du chemin+nom, c'est comme tu veux.

Je n'ai pas beaucoup réfléchi à ce modèle mais en gros voilà ce que je peux t'expliquer sur son fonctionnement:

la table listeEnregistrements contient des listes de musiques, si tu veux associer ces listes à un utilisateur alors tu peux ajouter une table utilisateur (contenant un id) puis un "idUtilisateurs" dans listeEnregistrements.

Pour la liste dont le numero vaut 10, tu trouveras une liste d'id de musiques (SELECT idEnregistrement FROM listeEnregistrements WHERE numero=10). Si la liste 10 contient 15 titres, alors tu auras 15 correspondances dans la table enregistrement.

Chacune de ces correspondances te permettra de connaître l'auteur de la musique en faisant SELECT * FROM auteur WHERE id=valeurDeIdAuteur. C'est le même principe pour le genre et le fichier.

Il reste un problème si tu as plusieurs auteur, enfin c'est pas un problème mais disons que dans cette version ce n'est pas possible de gérer ce cas. Il faudrait ajouter une table intermédiaires entre "enregistrement" et "auteur" pour ça. Le but de cette table serait de contenir des trucs comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
id   idAuteur   idEnregistrement
1    1              5
2    10            5
3    4              5
4    3              4
5    2              6

Dans ce cas on voit que l'enregistrement n° 5 est associé à 3 auteurs (1, 10, 4). Par contre l'enregistrement 4 et 6 n'ont qu'un seul auteur.

Bonne chance! J'espère que c'est compréhensible... mais bon si t'as jamais fait de modélisation ça risque de ne pas être super limpide.

[agent007se]

J'ai jamais fait de modélisation mais ça reste limpide (heu, c'est pas la fin du monde nom plus hein :p).

Le truc c'est qu'il n'y a qu'un seul et unique utilisateur et que la base est de type fichier... chose que j'aurais peut-être du préciser au départ...

Et, à ton avis, est-ce qu'il est possible qu'un utilisateur possède des mp3 de différents auteurs différents ? (C'est même quasi obligatoire...)

En gros :

-un fichier unique;
-valeur supérieure du nombre de fichiers : 10.000;
-(donc) un seul accès à la fois;

Et, pour finir, j'ai entre temps déjà implémenté ma base et son fonctionnement .... et ça fonctionne (j'ai ce que j'avais besoin d'avoir). A savoir un listing complet. Maintenant pour les fonctionalités avancées... je verrais ça une autre fois parce que j'ai un autre gros problème ailleurs (qui n'a rien avoir avec SQL).

Cela dit ma "Petite question supplémentaire" est toujours d'actualité .

En tous cas merci d'avoir essayé de m'aider (je tiendrais probablement compte de tes idées dans un futurs proche) !!

[yizashi]

Il y a quelque chose que je ne comprends pas, tu dis utiliser une base de données fichiers (du xml je suppose) et pourtant tu parles quand même d'SQL... alors qu'est-ce que tu utilises concrètement?

Personnellement je pense qu'une base de données est bien adaptée à ce genre d'application, en tous cas ce serait plus simple à mettre en place.

-----------------

Un utilisateur peut avoir plusieurs liste de mp3 et chaque mp3 peut avoir 1 ou plusieurs auteurs.

-----------------

Le principe de la modélisation c'est d'éviter les données redondantes. Par exemple si ton utilisateur a 50 mp3 d'un même auteur, alors il est un peu bête de réécrire 50 fois que l'auteur s'appelle John, qu'il est né en 1970, qu'il habite en Angleterre, etc.
Pourquoi c'est bête de faire ça? D'abord parce que si tu veux ajouter des infos sur ton auteur, il faudrait les répercuter à 50 endroits. Ensuite en terme de place c'est pas génial non plus. C'est pour ça qu'il faudrait plutôt avoir un fichier contenant la liste de tous les auteurs et ne modifier que ce fichier. Petit exemple (xml):

nom du fichier: auteurs.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<auteurs>
<auteur id="1" prenom="John" nom="Elton" anneeNaissance="1970"/>
<auteur id="2" prenom="Johny" nom="Halliday" anneeNaissance="1900"/>
</auteurs>

Ensuite dans les informations décrivant un mp3 tu devras avoir un attribut idAuteur par exemple:

Fichier mp3.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<enregistrements>
<enregistrement id="1" nom="unmp3deJohny" idAuteur="1" />
<enregistrement id="2" nom="unmp3deJohn" idAuteur="2"  />
</enregistrements>

Je n'ai pas trop compris ton principe de fichier unique, tu veux tout mettre dans un seul fichier ?

-----------------

Pour les questions supplémentaires :
le chemin complet me semble suffisant, mais ça dépend aussi de ce que tu veux afficher à l'utilisateur. Si tu affiches souvent le nom du fichier (sans son chemin), alors c'est peut-être plus pratique de séparer.

Pour la question des ID, je pense que le chemin absolu sera unique. En tous cas dans "mon" modèle, j'aurais un fichier (ou une table si tu utilises SQL) contenant TOUS les mp3. Pour chacun d'eux, il y a un id (un numéro qui commence à 1), si ton utilisateur a 1000 mp3, ça ferait 1000 <enregistrement> qui se suivent. L'un des attributs d'enregistrement, ce sera le chemin absolu. On pourrait l'utiliser comme id, mais en principe on préfère utiliser des numéros. Ca ne t'empêche pas de mettre l'attribut "chemin" comme étant unique.

Pour constituer les listes de l'utilisateurs, je fais référence à l'id des enregistrements.