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

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

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

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

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

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

edition question stupide

....
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

....
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"

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]

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.

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

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.

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 )

...
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