Page 1 sur 2
Clause LIKE
Posté : 19 sept. 2008, 17:13
par dunbar
Bonjour,
J'utilise une requête qui doit prend en compte un numéro exemple
J'ai un numéro de base qui est
OM26
et il a des enfants qui eux portent le numéro
OM26a ,OM26b ,etc...
Je n’ai pas de soucis ma requête fonctionne par contre si j'ai un numéro de base
OM26A il va me chercher aussi les enfants du OM26
Comment je pourrais contrer ce souci
Pour exemple ma requête et je sais que LIKE est insensible a la case mais je ne voie pas comment faire d'autre.
$sql_aff = "SELECT
al.noeud, al.number,al.id_lm, ad.number_dt, ad.id_dt, ad.noeud_dt, ad.adresse_dt
FROM
ampli_lm al, ampli_dt ad
WHERE
al.number = '".$numero_lm."'
AND
ad.number_dt
LIKE
'".$number_ligne."'
AND
ad.noeud_dt = al.noeud
";
D'avance merci
Posté : 19 sept. 2008, 17:42
par Truc
Salut,
C'est quoi cette histoire de trafic d'enfants ?
Sinon tu pourrai expliquer de nouveau... ce que tu as et ce que tu voudrais
Posté : 19 sept. 2008, 17:56
par dunbar
Salut,
C'est quoi cette histoire de trafic d'enfants ?
Sinon tu pourrai expliquer de nouveau... ce que tu as et ce que tu voudrais
Exemple:
J'ai des numéros maîtres et des eleves
Les maîtres ont comme numéro OM26 et les eleves de OM26 sont nommé OM26a OM26b, OM26c, etc...
Donc ma requête récupère bien le maître et les eleves comme ceci
OM26
|_____>OM26a
|_____>OM26b
|_____>OM26c
etc...
Mon soucis est qui ci j'ai un maître qui porte comme numéro OM26A
ces eleves sont OM26Aa, OM26Ab, etc....
Mais avec LIKE dans le cas présent il récupére tout les éléves OM26 il ne prend pas en compte le A ce qui est normal avec LIKE mais je ne voie d'autre solution.
D'avance merci
J'ai laisser les enfants pour m'attaquer aux eleves 
Posté : 19 sept. 2008, 18:07
par Truc
un défaut de conception ?!
il serait certainement plus facile de créer un nouveau champ (en bdd) "prof" pour les élèves.
En élève aura dans ce champ l'id de son prof... suffirait donc de récupérer tous les élèves ayant "OM26" dans ce champ... (pas très clair mes explications mais c'est presque le week end
Posté : 19 sept. 2008, 21:36
par dunbar
Bon alors un truc qui me chifone je pensais que le joker était obligatoire avec la clause LIKE
Alors que ci je fais LIKE mon_numero_ ca fonctionne trés bien et dés que je place le joker
mon_numero_ %
Alors ma question toute bête que risque t'il d'arriver ci je n'utilise pas le joker ?
D'avance merci
Posté : 20 sept. 2008, 10:12
par Ryle
Un LIKE sans joker, c'est possible, dans le jargon technique on appel ça communément un égal
Et autant le = va pouvoir se baser sur les index pour satisfaire ta requête rapidement, autant le LIKE (avec ou sans joker) va devoir se fader à chaque fois un fullscan de ta table...
Maitenant je comprend pas bien ton problème... si le numéro de ton prof est OM26A et que tu fais un LIKE 'OM26A%' il ne te retournera que les valeur commençant par OM26A... s'il te retourne tous les OM26, c'est que t'a oublié de coller le "A" dans le numéro du prof....
En revanche, un 'OM26A%' te retournera également le OM26a. Tu peux éviter cela de plusieurs manières. La première, c'est que par défaut MySQL est insensible à la casse pour certains type de champ. Cela peut se modifier, de manière à ce que 'OM26A' et 'OM26a' soient bien 2 chaines différentes (comme c'est le cas dans toute bonne bdd digne de ce nom
)
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...
HTH
Posté : 20 sept. 2008, 10:44
par dunbar
edition question stupide
Posté : 20 sept. 2008, 11:34
par Invité
....
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...
...
HTH
Salut,
Je suis tout a fait d'accord avec toi, et comme j'ai une tare sur les expressions régulières, j'ajouterai que l'on peut s'en passer en gardant la même idée de conception mais en utilisant la fonction length de MySQL. Ici on testera seulement la présence d'au moins un caractère (et non pas minuscule), mais dans ce cas ça devrait faire l'affaire!
A+
Rv
Posté : 22 sept. 2008, 10:21
par Truc
....
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...
...
HTH
Salut,
Je suis tout a fait d'accord avec toi, et comme j'ai une tare sur les expressions régulières, j'ajouterai que l'on peut s'en passer en gardant la même idée de conception mais en utilisant la fonction length de MySQL. Ici on testera seulement la présence d'au moins un caractère (et non pas minuscule), mais dans ce cas ça devrait faire l'affaire!
A+
Rv
Ou comment faire compliqué quand on peut faire simple
Je préfère une BDD bien faite que l'utilisation de "stratagèmes"
Posté : 22 sept. 2008, 16:15
par dunbar
Ou comment faire compliqué quand on peut faire simple
Je préfère une BDD bien faite que l'utilisation de "stratagèmes"
Tu pourrais développer stp
Et plus particulièrement ci tu avait à faire une table qui comprendrait 40 Champs.
[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]
Posté : 22 sept. 2008, 16:37
par zeus
il vaut mieux, et de loin, une table avec 80 champs de 1 caractère qu'une table de 1 champ de 80 caractères, c'est une règle de base.
Chaque champ doit contenir une données simple (vs composée de plusieurs données) afin que tout traitement SQL portant sur cette données soit simple.
Imaginons que le 5eme caractère soit un critère de recherche souvent utilisé dans le WHERE.
Avec ta solution (cad extraire le 5ème caractère du champ), MySQL va devoir remonter toute la table, extraire le caractère sur le 5ème champ, le tester et retourner les lignes qui correspondent.
Avec la solution standard (cad prendre la valeur dans le 5eme champ), MySQL optimise la requête en restraignant directement le choix sur les lignes voulues.
Et si tu veux mettre un index pour améliorer les performances, avec ta solution, c'est tout simplement impossible.
Voilà pourquoi il vaut mieux suivre les standards et créer beaucoup de champ, plutôt que de mettre en place des bidouillage pour gagner quelques champs.
Surtout qu'utiliser 80 champs de 1 caractères au lieu de 1 champs de 80 caractères n'est pas significativement plus lourd pour la base, mais infiniment plus rapide en traitement.
Posté : 22 sept. 2008, 17:30
par dunbar
Salut,
Et merci, j'avais peur d'avoir mal conçu ma base avec mes 40 champs.
et en effet chaque donnée a sont propre champs.
Par contre.
Imaginons une hiérarchie de pc avec un pc maître est ces éleves
Le pc maître porte comme numéro -> OM72 = champs de la base un champ BLOD
Et ces éleves portent comme numéro OM72a, OM72b, etc.... egalement un champ BLOD
Je ne voie pas comment il serais plus préférable d'enregistrée la numérotation.
Et dans ce cas précis le mouen le plus simple de connaître les éleves des maître est bien de faire un LIKE OM72_%
Ou y a t'il une meilleur méthode
Il est impossible de savoir combient il va ya avoir de maître et encore plus d'élèves je sais c'est bizarrre mais bon
Posté : 22 sept. 2008, 17:54
par Truc
placer un id auto-incrémenté (donc un int surtout pas de blob pour 5 caractères
) pour tout le monde... ajouter un champ "maitre".
pour l'entrée OM72 qui est un "maître" ce champ vaut null
pour les élèves ce champ contient l'id du maître (OM72).... tu peux donc facilement retrouver tous les élèves avec une jointure en partant du maître.
Posté : 22 sept. 2008, 17:57
par zeus
2 solutions :
Lorsque le maître change, que deviennent les enfants ?
exemple :
le maitre portait le numéro OM72 et devient OM80
Si les enfants doivent devenir OM80a, OM80b, ... alors il faut que tu décomposes le numéro des enfants en (numéro parent/id enfant)
Et si tu me dis que ce n'est pas possible, j'ai envie de te répondre que le client trouve toujours le moyen que ça devienne possible (genre, le parent est remplacé et tous les enfants doivent changer de parent
)
Posté : 22 sept. 2008, 18:18
par Invité
...
Ou comment faire compliqué quand on peut faire simple
Je préfère une BDD bien faite que l'utilisation de "stratagèmes"
[/quote]
...
Oui bien sûr le problème est avant tout au niveau de la conception : il vaut bien mieux faire du relationnel plutôt que du bricolage car il s'agit typiquement d'une relation 1..n. Mais bon il s'agit aussi de répondre à la question posée car nous sommes loin d'avoir tous les éléments sous la main pour savoir s'il vaut mieux revenir à la conception.
A+
RV