Discussion :

[mac7474]

Bonjour

Je voudrais joindre trois tables :
Attribuer (id_perso , id_aff , nb_heures)
Personnel (id_perso ,nom_perso)
Affaire (id_aff , d_date)

Voici le code (aidé par CinePhil) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
$requete = "SELECT p.id_perso, p.nom_perso, p.prenom,
  a.id_aff,
  SUM(a.nb_heures) AS nb_heures_total
FROM personnel p
 
INNER JOIN attribuer a ON a.id_perso = p.id_perso
 
where `id_aff` LIKE CONVERT( _utf8 '%$id_affaire%'USING latin1 )
AND `nom_perso` LIKE CONVERT( _utf8 '%$nom_agent%'USING latin1 )
GROUP BY p.id_perso, p.nom_perso, p.prenom, a.id_aff
ORDER BY a.id_aff , p.nom_perso, p.prenom  desc
             ";

Je voudrais rajouter une jointure avec la table affaire (dans laquelle il y a un champ d_date) qui croise la table attribuer via le champ id_aff, afin de filtrer les résultats par date (via un AND d_date>='$deb'and d_date<='$fi' )
Si je rajoute la ligne INNER JOIN affaire af ON af.id_aff = a.id_aff

il dit : Column 'id_aff' in where clause is ambiguous

Et si pour lever l'ambiguité je change la ligne par

where `a.id_aff` LIKE CONVERT( _utf8 '%$id_affaire%'USING latin1 )

ça me répond :
Unknown column 'a.id_aff' in 'where clause'

Quelle est mon erreur ?

Cordialement,
Philippe Rivière

[CinePhil]

Quand tu utilises les alias - et c'est important de les utiliser dès qu'une requête utilise plus d'une table - il faut les utiliser partout !

Et supprime donc ces saloperies d'apostrophes inversées inutiles dès lors que tes tables et colonnes sont correctement nommées !

Code :

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

1
2
3
4
5
6
7
8
9
SELECT p.id_perso, p.nom_perso, p.prenom,
  a.id_aff,
  SUM(a.nb_heures) AS nb_heures_total
FROM personnel p
INNER JOIN attribuer a ON a.id_perso = p.id_perso
WHERE a.id_aff LIKE CONVERT( _utf8 '%$id_affaire%' USING latin1 )
	AND p.nom_perso LIKE CONVERT( _utf8 '%$nom_agent%' USING latin1 )
GROUP BY p.id_perso, p.nom_perso, p.prenom, a.id_aff
ORDER BY a.id_aff , p.nom_perso, p.prenom  desc

Pourquoi es-tu obligé de t'emmerder avec les CONVERT ? id_aff devrait être de type entier, tout comme id_perso et tout identifiant de ligne d'une table issue d'une entité du MCD ou comme toute clé étrangère.

En plus, ta requête va être contre performante du fait du LIKE '%chaine%' et le CONVERT ne va pas arranger les choses ! J'espère que le volume de données n'est pas trop important sinon ça va ramer !

[mac7474]

Ok merci si je comprends bien c'est qu'il fallait utiliser les alias partout.
Maintenant cela fonctionne.

Ensuite pour les convert, curieusement si je ne les utilise pas, ça ne marche pas.

Enfin pour le LIKE '%chaine%' c'est pour pouvoir avoir qu'une seul requête même si les champs sont vides.

Par exemple, j'ai deux champs de recherche et avec LIKE '%chaine%' si les deux champs sont vide et que je lance une recherche ça recherche tout, sinon il faut que je fasse trois condition en fonction que les champs sont vide ou pas.

Mais si tu connais une façon d'avoir une seule requête sql sans le LIKE '%chaine%', ça m'intéresse.

Quand tu utilises les alias - et c'est important de les utiliser dès qu'une requête utilise plus d'une table - il faut les utiliser partout !

Et supprime donc ces saloperies d'apostrophes inversées inutiles dès lors que tes tables et colonnes sont correctement nommées !

Code :

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

1
2
3
4
5
6
7
8
9
SELECT p.id_perso, p.nom_perso, p.prenom,
  a.id_aff,
  SUM(a.nb_heures) AS nb_heures_total
FROM personnel p
INNER JOIN attribuer a ON a.id_perso = p.id_perso
WHERE a.id_aff LIKE CONVERT( _utf8 '%$id_affaire%' USING latin1 )
	AND p.nom_perso LIKE CONVERT( _utf8 '%$nom_agent%' USING latin1 )
GROUP BY p.id_perso, p.nom_perso, p.prenom, a.id_aff
ORDER BY a.id_aff , p.nom_perso, p.prenom  desc

Pourquoi es-tu obligé de t'emmerder avec les CONVERT ? id_aff devrait être de type entier, tout comme id_perso et tout identifiant de ligne d'une table issue d'une entité du MCD ou comme toute clé étrangère.

En plus, ta requête va être contre performante du fait du LIKE '%chaine%' et le CONVERT ne va pas arranger les choses ! J'espère que le volume de données n'est pas trop important sinon ça va ramer !

[skuatamad]

Qu'est ce que ça donne comme ça ?

Code :

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

1
2
WHERE a.id_aff = coalesce($id_affaire, a.id_aff)
  AND p.nom_perso = coalesce($nom_agent, p.nom_perso)

Par contre j'ai pas compris les convert qui sont peut être vraiment utile.

Mais ce n'est pas une bonne solution, il est préférable de construire dynamiquement la requête dans le code php en fonction des paramètres NULL ou non.
L'objectif est de soumettre au SGBD la requête qui correspond vraiment au besoin, comme ça le SGBD peut choisir d'utiliser un index pour certaines combinaisons de paramètre et un scan complet en l'absence de paramètre, par exemple.

[mac7474]

Quand je met ton code ça me renvoi ceci :

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' a.id_aff) AND p.nom_perso = coalesce(, p.nom_perso) AND d_date>='2011-01-' at line 7

Pour les convert, je pense que je dois les utiliser, du fait que la BDD doit être mal construite, genre des mélange d'UTF8 avec du latin...

"en fonction des paramètres NULL ou non" comment ça ?

Qu'est ce que ça donne comme ça ?

Code :

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

1
2
WHERE a.id_aff = coalesce($id_affaire, a.id_aff)
  AND p.nom_perso = coalesce($nom_agent, p.nom_perso)

Par contre j'ai pas compris les convert qui sont peut être vraiment utile.

Mais ce n'est pas une bonne solution, il est préférable de construire dynamiquement la requête dans le code php en fonction des paramètres NULL ou non.
L'objectif est de soumettre au SGBD la requête qui correspond vraiment au besoin, comme ça le SGBD peut choisir d'utiliser un index pour certaines combinaisons de paramètre et un scan complet en l'absence de paramètre, par exemple.

[CinePhil]

Pour l'erreur que tu rencontres, je pense qu'il faut entourer la variable PHP d'apostrophes. Mais je suis d'accord avec skuatamad : construit ta requête dynamiquement dans le code applicatif en fonction de ce qui est saisi par l'utilisateur. Et si tu peux éviter le CONVERT en remettant tout en UTF8, c'est mieux.