Bonjour tout le monde,
 
Je vais poser une question idiote, mais si je ne le fais pas je vais rester ignare toute ma vie :
Je souhaiterais enlever les doublons des résultats de ma requête. Je fais donc la requête suivante :

Cependant, j'aimerais retourner tous les champs des objets mstore_produits trouvés. Faut-il que je passe par une deuxième requête ou y a-t-il un moyen de le faire directement en une seule requête (du genre SELECT *, DISTINCT nom_prod ... je sais ça ne fonctionne pas).
 
Voila, merci d'avance.

bah tu rajoutes les champs que tu veux.
 
le distinct est une option qui s'applique à tous les champs du SELECT. Le requeteur va d'abord recuperer les enregistrements, et supprimer les doublons ensuite.

 
En fait je veux que le distinct ne s'applique qu'au champ nom_prod
Bon, je viens de lire que de toute façon la méthode "distinct" sent l'égout (dixit http://www.databasejournal.com/fea [...] hp/3437821 )
Pourquoi je me suis laissé embarquer dans les bases de données o_O

les like c'est pire que les distinct, donc tu vas aussi nous faire le plaisir d'utiliser FULLTEXT SEARCH

 
damned ! ^^
bon OK je sors, je recherche et je reviens  

va pas trop loin non plus, parceque les index sur texte, c'est quand même un peu compliqué, et ça résoudra pas forcément ton problème de distinct

 
hmm bon.. alors ça m'a l'air tout à fait passionnant, voir épanouissant comme sujet et je ne doute pas que je passerais un petit peu de temps dessus dès que mon boss arrêtera de me taper dessus ^^
 
Sinon, pour ma question du début, vous auriez des pistes à me donner ? une toute petite piste ? please ? s'il vous plait ?

c'est quoi la question en fait ? parceque c'est pas clair

y'a quoi dans ta base, tu veux trouver quoi ?

 
Euh le distinct ne sent pas l'egout. Il a une fonction, c'est tout.  

comme le like : on s'en sert que si on est menacé de malédiction sur les 10 génération à venir par un nain voodoo venant de l'espace

le like, la commande qui depanne quand on cherche quelque chose, mais que l'on ne doit jamais voir dans un script
 

 
Alors, dans ma base j'ai la table mstore_produits sur laquelle je fais mes tests pour trouver mes instances (si je dis un mot de travers tapez pas trop fort, c'est parce qu'à la base ce n'est pas tout à fait mon domaine).
 
mstore_produits
ref_prod
nom_prod
desc_prod
url_photo
prix
ref_categorie
modele
date_ajout
stock
promo
theme
prix_vert
valid
delai_livraison
ref_constructeur
 
Nous avons déjà un "moteur de recherche" (riez pas trop fort, la personne qui a programmé ça n'est pas là et il ne faut pas se moquer des absents) qui renvoie toutes les instances correspondant (soit dans nom_prod, soit dans desc_prod) à la chaine de caractères entrée. Ce que l'on m'a demandé de faire c'est d'enlever les doublons (et d'améliorer la présentation, ça c'est mon travail) retournés par ce moteur.
Le moyen d'enlever les doublons pour moi c'était de faire un distinct sur le champ nom_prod.
Ce que je dois retourner c'est des instances de la table mstore_produits (tous les champs quoi) correspondant à la recherche.
 
Ai-je été plus clair ?

tu ne veux pas que nom produit soit present plus d'une fois

 
n'importe quoi... il y a des cas (rare mais ils existent) ou le distinct est absolument obligatoire...

gravastar_ bureau > arrête pas parler "d'instances", parle de "produits", puisque c'est ce que tu as dans ta table. ça au moins ça parle à tout le monde, même à un enfant de 6 ans
sinon, si je comprends bien, le moteur actuellement renvoie plusieurs références produit différentes, qui ont le même nom de produit.
 
c'est bien ça ?
si c'est ça, alors c'est là qu'il faut creuser un peu : c'est pas normal.
 
ensuite, tu fais quoi si t'as un produit "PRD1" et un produit "PRD2" qui s'appelle tous les deux "mon produit" ? tu décides comment duquel afficher ?

Tamahome > ben justement, la menace de se faire désintégrer par un nain voodoo venu de l'espace est un des rares cas où il est autorisé d'utiliser distinct.
 
Pour le reste, c'est à éviter comme la peste.
 
En gros, t'imagine que le "distinct" et le "like" c'est une ligne blanche continue.
Ben en voiture, t'as pas le droit de la franchir de ton propre gré. mais si un gibiers se lance sous tes roues, ou qu'un ovni se pose devant toi, là t'as le droit de faire un écart sur la voie d'en face.

tu as bu ?

bah nan, je m'escrime à faire des modèles de données correct, et à les exploiter correctement, plutôt que d'utiliser des parades de sagouin pour pallier à un manque de réflexion.

j'oubliais : le "IN" est à mettre dans le même panier que le "DISTINCT" et le "LIKE". Le "IN", c'est même pire, puisqu'avec l'accroissement en taille de la base, une requête qui marchait très bien un jour va lamantablement planter le lendemain, de façon totalement alléatoire, parcequ'en certaines circonstances on aura dépassé le nombre maximal d'occurences acceptées par la clause "IN" (créfieu c'est de la bonne celle-là, ça me rappelle de bons souvenirs de nuits blanches en charmante compagnie - j'avais un jolie petit brin de stagiaire toute mimi pour m'aider à comprendre pourquoi la procédure de réplication d'une base plantait certaine nuits et pas d'autres )

Je resume ce que je sais :
DISTINCT : -> souvent utilisé a tort, dans 90% des cas on peut l'eviter en construisant autrement sa requete. JAMAIS une requete n'est plus performante avec un distinct qu'avec une autre solution...
 
LIKE: -> sur des requetes multicritères parfois inévitables et dans la plupart des SGBD n'utilise pas les indexs, a fuire aussi sauf obligation (il est d'ailleurs conseillé souvent de faire une requete dynamique avec un = ou un LIKE en fonction du nombre de critère (1 ou +) car le parsing est plus avantageux que la non utilisation de l'index, enfin surtout sur des gros volumes de données....)
 
IN : A remplacer par EXISTS systématiquement avec une auto-jointure et très souvent sans ... Le pourquoi du comment est un peu long a expliquer ici...J'essaierai de retrouver un article si ca interesse quelqu'un...

 
Alors c'est bien ça, pour le moment le moteur renvoie plusieurs produits qui ont le meme nom, car il s'agit d'un produit compatible avec plusieurs modèles de GSM (puisque c'est ce dont il s'agit). De ce côté-là, vu que ce n'est pas sensé être mon travail, je ne vais pas pouvoir creuser trop profondément.
 
Pour ce qui est de tes 2 produits "PRD1" et "PRD2", la réponse est au-dessus, en fait il s'agit du même produit.
 
Un embryon de piste pour éviter la double requête ?

de toute façon, là j'ai un bonhomme noir et rose à côté de moi qui tiens un objets étrange et menançant, donc j'ai le droit d'écrire :
 

 
ha nan, c'est le comptable qui venait me serrer la main.

ben oui, mais tu retournes quelle reférence dans ce cas alors ?
 
à mon avis, tu retournes trop de champs dans ta requête, c'est pour ça que ça merde.

 
Je retourne le produit sans préciser sa compatibilité sur cette page. Après, dans sa fiche produit, ses compatibilités seront listées.
 
Bon, je vais m'en sortir en fait, mais j'aurais aimé savoir s'il était possible de retourner tous les champs d'une table en évitant les doublons, en se basant uniquement sur un champ. Ca n'est pas forcement logique de faire quelque chose comme ça si la base est bien conçue, mais bon ^^

ben nan, c'est pas possible.
 
sinon, je répète la question : quand t'as un doublon sur ton champ, comment choisis-tu quelle ligne retenir plutôt que telle autre ?
 
un exemple :
 
Voici une table représentant l'arche de Noé (je dois me faire bâtiser, alors je révise)

 
select distinct bestilole, couleur from arche_de_noe
 
Ca donne :

 
OK, on a trouvé deux loup gris, donc on en a balancé un à l'eau.
Mais il reste deux lapins... Seulement, je balance lequel ? Le blanc ou le rose ? Ca, le SGBD il ne peut pas choisir à ta place. Il faut faut donc modifier ta requête pour lui dire sur quoi se baser pour discriminer les bestioles.

y'a un p à baptiser

moi je préfère l'écrire avec un "â" ça fait penser à âne bâté

 
Quel lapin choisir, je te dirais qu'en ce qui me concerne la chose importante est qu'il s'agisse d'un lapin.. après sa couleur m'importe peu.

donc, on est d'accord.
donc si tu vires la couleur de ta requête, t'aura plus de problème.
 
idem pour ta requête : si avec un distinct t'as encore des doublons, alors c'est que tu retournes un champ discriminant dont tu te moques : vire-le !

dans ce cas, pourquoi recuperer le champ sur la couleur?

grillaide, nananère

 
Vous avez tout à fait raison, je voulais récupérer toutes les infos relatives aux produits à afficher pour ne pas dépayser la personne qui a fait ce script. Comme la base et l'ensemble des requêtes faites sur ce site me semblent louches, je ne veux pas tout changer o_O

oui