Vous n'êtes pas identifié(e).
Bonjour à tous,
Le titre parle de lui-même car le sujet est très mal documenté sur le net, bien que la question ait déjà été posée principalement dans des forums professionnels de langue anglaise.
Alors, j'ai été très déçu par ces forums, du moins de part les gens, censés être la crême de la crême du SGBDR, les pros du MySQL, bref je vous passe les qualificatifs, car au lieu d'y avoir trouvé l'expression de leur savoir et de leur maîtrise du SQL, j'y ai pu lire des " LOL pourquoi tu as besoin de requêter une table vide?... quel intérêt..." et j'en passe.
Toutes ces remarques sont tellement évidentes au premier abord, que ces messieurs ont tout simplement oublié, .... qu'une table est vide avant de contenir des données !!! Les requêtes de production d'une application doivent donc pouvoir aussi gérer la vérification, l'insertion et la non modification du premier enregistrement, auquel cas l'application n'est pas utilisable lors de son premier jour d'utilisation.
Voilà pour les explications contextuelles.
Maintenant, vu qu'il s'agit d'un forum de débutant, il faut bien l'avouer, les bases de données gérées par les arpenteurs des rubriques de PHPdébutant sont statistiquement plus vides que pleines (plus de 100Mo de données). Ne parlons pas de Go, cela ne sert à rien ici.
C'est pourquoi je poste ce sujet qui pourra vous faire gagner un temps énorme (chance que je n'ai pas eue, car cela m'a fait perdre 1h30 de dev...)
Alors, comme le titre l'indique, MySQL ne supporte pas du tout un LEFT OUTER JOIN (OU LEFT JOIN) sur une table vide et retournera une erreur systématiquement. Comment contourner le problème? Voici la solution que j'ai trouvé pour ceux que cela interesse.
Attention cependant à ce que le choix du champX rajouté dans la condition HAVING n'impacte en rien le contexte de filtrage de la requête dérivée sur la table source (du coté gauche de la relation ici) sinon, lorsque votre table2 contiendra des enregistrements, les résultats de votre requête risquent de ne pas être cohérents.
EDIT: De plus dans mon cas ici champX est un INT unsigned not null dans sa définition. Par conséquent ce choix dans ma requête fait que l'index ne sera pas utilisé dans la requête lorsque la table contiendra des enregistrements, car non pertinent dans le contexte. Donc aucune incidence de performance ultérieure.
Cordialement,
Jc
Dernière modification par Jc (17-10-2011 18:10:13)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Saluton,
Permets-moi deux remarques Jc,
Tout d'abord ce n'est pas tout à fait la même chose de faire une jointure entre deux tables que de faire une jointure entre une table et le résultat d'une sous-requête comme c'est le cas ici. La sous-requête ne retournant rien, la table mémoire résultante n'est pas créée par MySQL, et, partant, sa structure n'existe pas donc, les colonnes référencées par la jointure n'existant pas (en tant que structure) le moteur retourne un message d'erreur.
Si la jointure avait porté sur la table elle-même le moteur aurait su implémenter la requête.
Ce comportement, s'il s'explique, n'en demeure pas moins inacceptable.
Ensuite, je doute que tu aies posé ta question sur le forum MySQL des développeurs, car sinon, je l'aurais vue et, plus important, des gens bien plus compétents que moi comme SQLpro, Ced ou Cinephil, n'auraient pas manquer de t'apporter une réponse.
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Merci MK;)
Ps: Pour tout te dire, je n'ai posté nulle part, et donc à tort, j'ai du trouver la solution seul.
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne