|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||
|
Membre à l'essai
![]() Inscription : avril 2006 Messages : 87 ![]() |
Bonjour,
voila je tourne en rond depuis 2 jours sur un pb de jointures liant 4 tables. Tout va bien tant que je lui demande pas d'afficher un certain type de données. voici ce que j'obtiens en visuel : Citation:
Code :
Citation:
J'ai beau faire la requete dans un sens comme dans l'autre c'est à dire partir de la table commande -> table stock historique (ce qui là n'est plus logique), le problème reste le même, l'affichage cafouille quand je lui demande les informations contenues dans la table commande_contenu... hors ce sont les informations les plus importantes je ne sais plus quoi faire si quelqu'un a une idée je suis preneuse. merci par avance. |
||||
|
|
00
|
|
|
#2 |
|
Expert Confirmé
![]() ![]() Avcxjo MoKoRetraité Inscription : novembre 2005 Messages : 2 527 ![]() |
Saluton,
Ta jointure ne se fait pas entre 4 mais 6 tables, et le GROUP BY risque de ne rien arranger.
__________________
Kie lumo eksistas ankaŭ ombro troviĝas. L.L. Zamenhof articles : Comment émuler un tableau croisé [quasi] dynamique et : Une énigme mathématique résolue avec MySQL recommande l'utilisation de PDO (PHP5 Data Objects) |
|
00
|
|
|
#3 | ||
![]() ![]() |
Pourquoi faire un GROUP BY alors qu'il n'y a pas de fonction d'agrégation dans ton SELECT ?
USING empêche de savoir quelles tables sont jointes. Avec quelle table est jointe la table produit ? Avec quelle table est jointe la table commande_contenu ? Dans le LEFT JOIN, tu n'as pas indiqué à quelle table appartient la colonne sous_pack_id. Pour toutes ces raisons, ta requête est un peu difficile à analyser car on voit mal l'enchaînement des jointures. Pour une meilleure lecture, je te conseille aussi d'utiliser des alias. Et tant qu'à faire, évite la guerre des étoiles ! C'est peut-être trop tard mais un id_client en chaîne de caractères, c'est pas top ! Il vaudrait mieux un identifiant entier auto-incrémenté. Voici ta requête partiellement récrite : Code :
__________________
Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework... « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau) À la maison comme au bureau, j'utilise Mandriva Linux ou Mageïa ! Soutenons l'industrie logicielle française ! Linuxiens, comptez-vous ! |
||
|
00
|
|
|
#4 | |||
|
Membre à l'essai
![]() Inscription : avril 2006 Messages : 87 ![]() |
Citation:
Code :
Je n'ai pas mis d'alias parce que je ne suis pas la seule à utiliser ce code et donc respect pour ceux qui travaille avec moi.. et je n'ai pas mon mot à dire vu que je ne suis que stagiaire pour les sous_pack_id, je n'ai pas mis le nom de colonne tout simplement parce que dans toute ma base il n'y a qu'une seule correspondance. l'id client vient d'un annuaire ldap, je ne vais pas m'amuser à critiquer le travail de l'administrateur réseau qui l'a mis en place mais ça tu pouvais pas le savoir ^^ mais bon en gros, j'ai changé ma requête, elle servait à la base à afficher des produits par numéro de pack (stock_cmd) que je ressort en tableau grace aux 2 fetch. J'ai triché via un if sur php pour ne pas afficher les produits seuls et vice versa. ça ne résout en aucun cas ma requête sql mais on va dire que c'est une solution d'appoint moins prise de tête :p |
|||
|
|
00
|
|
|
#5 | ||||||
![]() ![]() |
Citation:
![]() J'imagine bien que la première jointure concerne stock_historique et stock mais produit est-elle reliée à stock_historique ou à stock ? Le contenu du SELECT laisse à penser que c'est avec stock. Citation:
![]() MySQL est trop permissif sur la syntaxe du GROUP BY. Comme tu fais un GROUP BY seulement sur stock.stock_id, seules les colonnes directement dépendantes de stock_id, c'est à dire celles de la table stock resteront invariables. Pour toutes les autres, MySQL affichera la première valeur qu'il trouve obéissant à la jointure avec la table stock ! La raison est que les colonnes du SELECT ne faisant pas l'objet d'une fonction de regroupement (SUM, AVG, MIN, MAX, COUNT) doivent toutes figurer dans le GROUP BY. Un autre SGBD aurait rejeté ta requête ! Citation:
Il y a deux fois commande_contenu.stock_cmd dans ton SELECT ! Avec les alias, peut-être que tu l'aurais vu ! ![]() Citation:
Encore une fois, en supprimant l'ambiguïté, on rend la requête plus lisible et compréhensive et on évite de potentielles erreurs. Et tu vois que pour t'aider dans le cadre de ce forum, ça ne facilite pas les choses ! Citation:
![]() L'identifiant LDAP est une chose, l'identifiant dans la table de la BDD en est une autre. L'identifiant LDAP être un attribut significatif et doté d'une contrainte d'unicité mais est une mauvaise clé pour une table dans un SGBDR. Dans mon précédent message, je t'ai mis le lien vers l'article qui explique les avantages de l'identifiant anonyme et auto-incrémenté par rapport à un identifiant signifiant et alpha-numérique. Citation:
Il reste difficile de t'aider à simplifier cette requête mais en tout cas, supprime ce GROUP BY qui est probablement la source de l'erreur dans le résultat que tu affiches dans ton premier message ! La structure des tables pourrait aider à la compréhension.
__________________
Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework... « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau) À la maison comme au bureau, j'utilise Mandriva Linux ou Mageïa ! Soutenons l'industrie logicielle française ! Linuxiens, comptez-vous ! |
||||||
|
00
|
Copyright © 2000-2012 - www.developpez.com