Discussion :

[Guizmo95]

Bonjour,

Je suis actuellement à la phase d'étude pour un site internet réalisé en php / MySQL.

Mon besoin est le suivant :

Une table utilisateur (avec les infos de l'utilisateur )
Une table type de musique (avec id_type_music et nom_type_musique)
Une table intermédiaire reliant les deux tables (id_type_musique et id_utilisateur)

Ma question est la suivante :
Quel serait la solution la plus optimisée en terme de temps de réponse et aussi en terme de ressource serveur :

1 - laisser tel quel

2 - supprimer la table "type de musique", puis dans le code PHP avoir en "dur" la liste des type de musique avec leurs ID + nom et insérer l'ID dans la table intermediaire

3 - Solution intermédiaire : supprimer la table "type de musique", ajouter le champ "nom_type_musique" dans la table intermédiaire ce qui nécessite d'avoir des constantes dans le code php pour l'insertion et aucune conditions du type [...] if(id_type_musique=="jazz") then $type="jazz" [...] pour la lecture

Mes points interrogations :

La solution 1 me permet de pouvoir rajouter un style de musique rapidement (même si ça ne devrait pas beaucoup bouger) mais cela me fait une table en plus et cela m'oblige aussi à faire une requête avec une jointure du type :

select t.nom_type_musique
from type_musique t, intermediaire i
where i.id_type_musique=t.id_type_musique
and i.id_client=12504

Alors que si je supprime la table "type de musique" je n'aurais plus de jointure à faire et j'aurais une table en moins dans ma base. Par contre, php devra prendre la relève. En effet, après avoir reçu la liste des id_type_musique via une requête SQL, il faudra faire un [...] if(id_type_musique=="jazz") then $type="jazz" [...] (et ainsi de suite) ce qui peut prendre de la ressource serveur.
De plus, cette table ne serait pas la seule (exemple : type_film, type_livre...)

La solution 3 me semble la plus adaptée sachant que pour l'insertion je n'aurais qu'a récupérer le nom des type de musique via des constantes dans le code et que pour la lecture je n'aurais qu'a afficher le résultat de la requête suivante :

select i.nom_type_musique
from intermediaire i
where i.id_client=12504

Merci pour le retour que vous pourrez me faire à ce sujet

[CinePhil]

La première solution est la meilleure.
Il ne faut pas avoir peur des jointures, c'est l'opération la plus optimisée dans un SGBD car c'est son boulot principal de joindre des tables pour extraire des résultats.

Le code du programme utilisateur ne doit pas influer sur la structure de la BDD, c'est au contraire au code de s'adapter à la structure.

Si tu ne veux pas faire les jointures dans ton code, fais une vue et interroge la vue dans ton code.

Et au passage, les jointures s'écrivent depuis 1992 avec l'opérateur JOIN ; il serait temps de s'y mettre !

[Sergejack]

La première solution est en effet l'idéal.
Il suffit de bien penser les index.

Si votre DB doit souvent répondre à "Untel écoute quelles musiques ?" il vous faut l'index id_utilisateur, id_type_musique.
Si votre DB doit souvent répondre à "Qui écoute telle musique ?" il vous faut l'index id_type_musique, id_utilisateur.

[Guizmo95]

Merci pour les réponses que vous avez pu m'apporter je vais suivre vos conseil.

Et oui effectivement les jointures s'écrivent avec JOIN my fault

Par contre que pensez vous de cette affirmation :

#Remplacer une jointure par une sous-requête. Par exemple :

Code :

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

1
2
3
 
SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN (
  SELECT column1 FROM t2);

au lieu de

Code :

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

1
2
SELECT DISTINCT t1.column1 FROM t1, t2
  WHERE t1.column1 = t2.column1;

Qui vient du site de MySQL (http://dev.mysql.com/doc/refman/5.0/...ubqueries.html)

Faut-il privilégier les sous requêtes plutôt que les jointures et jusqu'à quelle point? cela marche peut-être que pour les requêtes simple?
Ou bien la jointure avec JOIN reste la plus optimisée par rapport à une sous requêtes même si elle est simple?

[CinePhil]

Par contre que pensez vous de cette affirmation :

#Remplacer une jointure par une sous-requête. Par exemple :

SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN (
SELECT column1 FROM t2);

au lieu de

SELECT DISTINCT t1.column1 FROM t1, t2
WHERE t1.column1 = t2.column1;

Qui vient du site de MySQL (http://dev.mysql.com/doc/refman/5.0/...ubqueries.html)

Cette mauvaise idée n'est pas flatteuse pour MySQL qui devrait vérifier ce qu'il y a dans sa doc ! Idée saugrenue et syntaxe de jointure obsolète depuis bientôt 20 ans !
Si SQLPro passe par là, il va encore pouvoir dire tout le mal qu'il pense de MySQL !

Faut-il privilégier les sous requêtes plutôt que les jointures et jusqu'à quelle point? cela marche peut-être que pour les requêtes simple?
Ou bien la jointure avec JOIN reste la plus optimisée par rapport à une sous requêtes même si elle est simple?

Je crois que ma remarque précédente répond à la question non ?

[Guizmo95]

ok ok, donc prioriser JOIN et utiliser les sous requêtes que lorsqu'on ne peux pas faire autrement .

Moi qui pensais pouvoir faire confiance au site de MySQL

L'optimisation de BDD et de requête m'intéresse mais du coup je ne sais pas où chercher vu que même MySQL ne donne pas toujours de bon conseils.

Avez vous un ouvrage ou lien à me conseiller pour que je puisse approfondir?