Problème PHP/MySQL assez complexe - PHP - Programmation
Marsh Posté le 19-11-2002 à 16:54:32
purée ce que c'est crade....
déjà, commence par utiliser une syntaxe plus propre (mais tout autant correcte) pour tes jointures, ça te permettra de t'y retrouver plus facilement, eh puis alias un peu ça facilite la lecture
SELECT
A.machin,
B.truc
FROM latable AS A
LEFT JOIN latable AS B ON condition pour que ça jointe
et après tu pourras (beaucoup plus facilement) ajouter tes clauses where de recherche.
si tu me files une requête propre, avec juste un champ ou une condition par ligne je te filerai un ocup de main pour le code pour modifier la requête et faire la recherche en php.
là avec tout les noms qui se ressemblent et la longueur du truc c'est illisible
Marsh Posté le 19-11-2002 à 16:58:52
Sh@rdar a écrit a écrit : purée ce que c'est crade.... déjà, commence par utiliser une syntaxe plus propre (mais tout autant correcte) pour tes jointures, ça te permettra de t'y retrouver plus facilement, eh puis alias un peu ça facilite la lecture SELECT A.machin, B.truc FROM latable AS A LEFT JOIN latable AS B ON condition pour que ça jointe et après tu pourras (beaucoup plus facilement) ajouter tes clauses where de recherche. si tu me files une requête propre, avec juste un champ ou une condition par ligne je te filerai un ocup de main pour le code pour modifier la requête et faire la recherche en php. là avec tout les noms qui se ressemblent et la longueur du truc c'est illisible |
ça changera rien, faire des AS partout ne rend pas les choses plus lisible... Quand à un LEFt JOIN tu m'expliquera l'intéret, MySQL le transforme tout seul en jointure comme je l'ai écrite...
Je peut pas rendre ça moins crade comme tu le dit (je trouve ça même assez clair...) car je joint 4 tables dans une seule requete...
Marsh Posté le 19-11-2002 à 17:06:10
desolé, jai pas lu en entier, pe quand je ne travaillerais pas, mais si tu veux faire un IN (select ...)
A laide d'une premiere requete, genere une liste d'element (xxx,xxy,xyx,yxx) et utilise la dans ta derniere requete IN (xxx,xxy,xyx,yxx)
Si cela nest pas utile a ton probleme, dsl .
Marsh Posté le 19-11-2002 à 17:07:53
l'avantage c'est que les clauses AND ne servent qu'aux clauses WHERE, ça évite de se mélanger les pinceaux entres les jointures et les recherches.
le fait d'aliaser c'est uniquement parce que tes champs et tes noms de table portent des noms quasi identiques
tout ça est souvent cause d'erreurs ou de confusion, surtout quand tu jointe sur plusieurs tables.
moi je préfère ça :
Code :
|
EDIT : j'oubliais le plus important : je fais ça pour te filer un coup de main, si t'en veux pas, dis-le, je vais pas te forcer.
Marsh Posté le 19-11-2002 à 17:13:57
Sh@rdar a écrit a écrit : l'avantage c'est que les clauses AND ne servent qu'aux clauses WHERE, ça évite de se mélanger les pinceaux entres les jointures et les recherches. le fait d'aliaser c'est uniquement parce que tes champs et tes noms de table portent des noms quasi identiques tout ça est souvent cause d'erreurs ou de confusion, surtout quand tu jointe sur plusieurs tables. moi je préfère ça :
|
Je vois bien ce que tu veux dire mais comme je place mes jointure en prmeier lieu on les sépares assez bien... Surtout que j'ai besoin de jointures internes et non externes, d'ou la non-utilisation d'un LEFT JOIN.
Petit rappel de la doc MySQL :
Citation : 5.2.6 How MySQL Optimizes LEFT JOIN and RIGHT JOIN
|
Mais bon, ça fait pas avancer mon shmilblick là Merci quand même de m'aider
Marsh Posté le 19-11-2002 à 17:17:21
je sais tout ça, le problème c'est que je connais aussi un peu les mecs qui trainent par ici
tout le monde ne va pas prendre la peine d'indenter / modifier tes requêtes et tes structures de table juste pour te dépanner.
je prend les devants en te demandant de fournir une requête mieux formée histoire de t'aider plus rapidement, ça sera bien plus simple pour tout le monde.
Marsh Posté le 19-11-2002 à 17:20:18
Sh@rdar a écrit a écrit : je sais tout ça, le problème c'est que je connais aussi un peu les mecs qui trainent par ici tout le monde ne va pas prendre la peine d'indenter / modifier tes requêtes et tes structures de table juste pour te dépanner. je prend les devants en te demandant de fournir une requête mieux formée histoire de t'aider plus rapidement, ça sera bien plus simple pour tout le monde. |
Heu... Honettement en quoi ces requetes sont mal formées ?
Marsh Posté le 19-11-2002 à 17:23:59
ah là là, c'est juste que pour quelqu'un qui connait les tables (toi en l'occurence) c'est facile à lire (quand je dis malformées c'est plutôt illisibles en fait)
moi je vois plein de criteres_ truc, criteres_machin, ça me prend 3 fois plus de temps à lire et à comprendre..
en plus avec un champ ou une condition par ligne ça rend le truc ultra clair.
c'est comme lire du code non-indenté, c'est beaucoup plus chiant pour celui qui ne l'a pas tapé.
Marsh Posté le 19-11-2002 à 17:30:04
Fred999 a écrit a écrit : Bruce, si tu pouvais mettre un mini-MPD, ça aiderait |
Voilà
Marsh Posté le 19-11-2002 à 17:34:17
Sh@rdar a écrit a écrit : ah là là, c'est juste que pour quelqu'un qui connait les tables (toi en l'occurence) c'est facile à lire (quand je dis malformées c'est plutôt illisibles en fait) moi je vois plein de criteres_ truc, criteres_machin, ça me prend 3 fois plus de temps à lire et à comprendre.. en plus avec un champ ou une condition par ligne ça rend le truc ultra clair. c'est comme lire du code non-indenté, c'est beaucoup plus chiant pour celui qui ne l'a pas tapé. |
Vi vi je comprend bien... Escuse moi si je suis un peu rude mais ça fé des heures que je suis là dessus, mon parton ça le fé chier car j'avance pas... Bref voilà quoi
Marsh Posté le 19-11-2002 à 17:34:52
req1 : facile (d'ailleur, tu le dit, ca marche)
req2 : ca peut pas marcher (un champ ne peut pas avoir deux fois la même valeur à la fois)
req3 : il y a des risques de confusion dans l'ordre d'éxécution des conditions
req4 : bonne mais risque de doublons
req 5 : trop compliqué (a mon avis) il existe plus simple pour faire pareil
Essayes donc ça :
Code :
|
PS : LE distinct est peut être pas placé sur la bonne colone, je conais pas tes besoins.
PPS : Si t'as besoin de plusieurs colones en distinct alors il faudra que tu retraite dans ton programme le résultat de la requête 4 (utilises un order by dans ta requête si tu veux te facilité la vie)
Marsh Posté le 19-11-2002 à 17:36:53
omega2 a écrit a écrit : req1 : facile (d'ailleur, tu le dit, ca marche) req2 : ca peut pas marcher (un champ ne peut pas avoir deux fois la même valeur à la fois) req3 : il y a des risques de confusion dans l'ordre d'éxécution des conditions req4 : bonne mais risque de doublons req 5 : trop compliqué (a mon avis) il existe plus simple pour faire pareil Essayes donc ça :
|
Je regarde ça merci...
Pour la 4 en fait ça marche plus ou moins, mais le problème c'est que le champ "user_criteres_value" est testé sur toutes les valeurs de la table... Bref si je cherche "01" dans le login et qu'il as "01" dans le numéro de téléphone, bha j'ai également la ligne du téléphone retournée...
Marsh Posté le 19-11-2002 à 17:40:13
Bruce a écrit a écrit : Je regarde ça merci... Pour la 4 en fait ça marche plus ou moins, mais le problème c'est que le champ "user_criteres_value" est testé sur toutes les valeurs de la table... Bref si je cherche "01" dans le login et qu'il as "01" dans le numéro de téléphone, bha j'ai également la ligne du téléphone retournée... |
Si c'est le cas alors c'est que le Criteres.Criteres_id est mal informé (même valeur opour le numéro de téléphone que le login). Sinon, je vois pas pourquoi ca arriverait.
Marsh Posté le 19-11-2002 à 17:45:27
omega2 a écrit a écrit : Si c'est le cas alors c'est que le Criteres.Criteres_id est mal informé (même valeur opour le numéro de téléphone que le login). Sinon, je vois pas pourquoi ca arriverait. |
Bon, je sais pas ça le fait plus là... Grml ce truc me rend fou
Marsh Posté le 19-11-2002 à 17:52:45
Oki, bon, oui ça marche mais pas exactement comme je voudrais...
Là on arrive à récupérer tous les utilisateurs qui répondent à au moins UN des critères, mais ce dont on as besoin réellement c'est qu'ils répondent à TOUS les critères... c'est pour ça que j'ai essayé avec un AND au début (ce qui évidement ne marche pas :'().
ouinnnn
Marsh Posté le 19-11-2002 à 18:24:35
Bruce a écrit a écrit : Oki, bon, oui ça marche mais pas exactement comme je voudrais... Là on arrive à récupérer tous les utilisateurs qui répondent à au moins UN des critères, mais ce dont on as besoin réellement c'est qu'ils répondent à TOUS les critères... c'est pour ça que j'ai essayé avec un AND au début (ce qui évidement ne marche pas :'(). ouinnnn |
Le plus simple alors, c'est de laisser tomber le distinct, de faire un "order by Criteres_id " à la fin (à la palce du "group by ..." ).
Tu te fait un tableau crit[] contenant la liste des critaires et les valeurs associés
Tant que tu est sur le même Criteres_id que la première ligne, tu continus à remplir un tableau d'enregistrement (structure d'enregistrement équivalent à celle de la requête sql) contenant les diférentes colones ramené par ta requête.
A chaque fois que tu change de Criteres_id, tu copies ton tableau dans un autre et tu vides le premier.
Tu met la valeur "" dans la case du tableau crit[] qui corespond
Pour chaque ligne, tu vérifies que le "userid.uid" existe bien dans le second tableau et s'il y existe, tu le recopie dans le premier.
Arrivé à la fin de la liste, il te reste plus que ceux qui corespondent à tout tes critaires.
Un dernier truc, si tu trouves une case du tableau crit[] qu'est pas à "" alors c'est qu'il n'y a aucune réponses corespondants à ce qui est demandé.
Marsh Posté le 19-11-2002 à 18:53:54
omega2 a écrit a écrit : Le plus simple alors, c'est de laisser tomber le distinct, de faire un "order by Criteres_id " à la fin (à la palce du "group by ..." ). Tu te fait un tableau crit[] contenant la liste des critaires et les valeurs associés Tant que tu est sur le même Criteres_id que la première ligne, tu continus à remplir un tableau d'enregistrement (structure d'enregistrement équivalent à celle de la requête sql) contenant les diférentes colones ramené par ta requête. A chaque fois que tu change de Criteres_id, tu copies ton tableau dans un autre et tu vides le premier. Tu met la valeur "" dans la case du tableau crit[] qui corespond Pour chaque ligne, tu vérifies que le "userid.uid" existe bien dans le second tableau et s'il y existe, tu le recopie dans le premier. Arrivé à la fin de la liste, il te reste plus que ceux qui corespondent à tout tes critaires. Un dernier truc, si tu trouves une case du tableau crit[] qu'est pas à "" alors c'est qu'il n'y a aucune réponses corespondants à ce qui est demandé. |
Je vois l'idée... Je vais essayer de faire un truc du genre...
Marsh Posté le 19-11-2002 à 16:19:49
A tout hasard je me demande si quelqu'un aurrais pas une solution à mon
problème... voilà bien deux jours que je bloque dessus...
Je développe une application en PHP et là j'arrive pas à m'en sortir avec
les requettes SQL.
Petite explication.
La base se présente ainsi :
table 1 : userid
Cette table contient la liste des utilisateurs avec un identifiant "uid"
unique auto-incrémenté, ainsi que le "username".
table 2 : Criteres
Cette table contient les critères. En résumé les critères sont tous les
différents paramètres possibles des utilisateurs, tels que le nom, age,
ville, centres d'intérets... La table contient donc (entre autre, je met que
l'essentiel) un identifiant unique auto-incrémenté de critère "Criteres_id"
et un nom pour chaque critere "Criteres_nom".
table 3 : Criteres_pages
Les critères sont regroupés par pages, cette table liste donc ces
différentes pages. Comme toujours, un identifiant unique "Criteres_pages_id"
et un nom "Criteres_pages_nom". On relie la table 3 avec la table 2 en
mettant "Criteres_pages_id" comme clef étrangère dans la table 2.
table 4 : user_criteres
C'est la table en relation entre les critères et les utilisateurs. C'est
dans cette table qu'on stocke les valeurs des critères pour chaque
utilisateur. Comme toujours, une clef unique auto-incrémentée
"user_criteres_id", un champ de valeur "user_criteres_value" et en clef
étrangères les deux clef des tables userid et Criteres, soit "uid" et
"Criteres_id" respectivement.
Là ou je bute c'est sur la réalisation d'un moteur de recherche
d'utilisateur par ses valeurs de critères. J'ai fait un formulaire qui
permet de lancer une recherche par au moins un paramètre (username, nom
réel, prénom, email), mais voilà, bien complexe de faire la requete SQL
adéquate pour récupérer une liste d'utilisateurs répondants à ces
critères... Si pour un seul critère cela marche très bien (en sachant que le
critère numéro 29 est celui du nom réel) :
Cela deviens autrement plus complexe d'ajouter un second critère de
recherche...
Ne marche pas, pas plus que :
ou encore :
Le seul moyen que je vois d'avoir une réponse correcte serait d'utiliser les
sous-requetes :
Mais j'ai pas franchement envie d'attendre la sortie de MySQL 4.1...
Si quelqu'un as une idée... Merci d'avance !
---------------
A+++ Bruce - http://www.bheller.com