Sql: where nom like dans un sql déjà existant

Tu peux limiter le cas échéant avec un IN :

SELECT toto FROM table WHERE titi in ('a','b','c') and toto in ('paris','lyon');

Bonjour,

Concernant: WHERE champ1, champ2 = truc;

Il faut un opérateur logique. Vous en avez deux: AND et OR

Leur précédence est équivalente à * et + en arithmétique. Exemple:

(3 + 2) * 5 est différent de 3 + (2 * 5)

Si je remplace * et + par AND et OR, j'aurai

WHERE (x = 3 OR y = 2) AND z=5
WHERE x=3 OR (y=2 AND z=5)

ces opérateurs AND et OR sont incontournables.

Donc, il faut:

WHERE champ1='xxx' AND champ2='xxx'

prenons le cas d'une bdd. Vous voulez sortir tous les hommes sans distinction d'âge et toutes les femmes entre 20 et 35 ans:

SELECT * CLIENTS
WHERE sexe='H' OR (sexe='F' AND age BETWEEN(20,35)

C'est clair?

A+

Il faut limiter les filtres sur données. Avec de très grosses base de données, le filtrage est très fortement ralenti sur des champs non indexés

je vais aussi aller voir les info sur IN avant ;)

Bonne idée, parce que sans vouloir te vexer... tu n'y es pas du tout pour le IN ;-)

Bonsoir,

IN sert à déterminer si une donnée figure dans une collection.

Exemple:

SELECT * FROM ma_table WHERE jour = 'lundi' OR jour = 'mercredi'

peut se remplacer par:

SELECT * FROM ma_table WHERE jour IN('lundi','mercredi')

Un exemple plus frappant. Vous voulez isoler x communes dans une base:

SELECT * FROM ma_table WHERE code_postal IN ('75012','75013','75014','75015')

sachant que le IN(...ma collection...) peut être très long, c'est quand même plus compact que ceci:

code_postal = '75012' OR code_postal = '75013'.....

A+

Le % est en principe réservé au like, mais il faut voir ce que ton SQL est prêt à gober !
Par contre, la double recherche n'existe pas encore dans aucun SQL...

Bjr,

CITE: ... est-ce que je peux utiliser les % comme avec like pour demande a ce qu'il trouve le mot parmi tous les mots ?

REPNSE: je n'ai pas essayé, mais peut-être ça marcherait...

CITE: ...est-ce que je peux faire cette même requête avec 2 champs qui cherche les mêmes mots, genre :
WHERE (monchamp1, monchamp2) IN ('%mot1%', '%mot2%");

REPONSE: Non, c'est ceci qu'il faudrait faire:
WHERE monchamp1 IN ('%mot1%', '%mot2%") OR monchamp2 IN ('%mot1%', '%mot2%") ;

A+

Ton exemple est mal posé, n'oublie pas que les champs sont testés ligne à ligne, donc 75021 de champ1sera lu en même temps que 75029 de champ2...

C'est bien pour cela que je pose ces question
En général j'utilise like pour faire ça mais like ne permet pas la recherche de plusieurs mots dans plusieurs champs.
Je prend un exemple que je trouve plus clair.

Champ 1 : Je pense donc je suis
Champ 2 : Je suis mais.. est ce que je pense ?

Je veux récupérer tous les réponses quand le champ et et le champ2 contiennent "suis" ET "pense"

Donc si je conclue : Impossible avec IN d'économiser des la taille de ma requête qui va finir par etre très longue a force d'ajouter des mots à chercher dans des titres, descriptions et mots clé en plus des filtres que j'ai déjà.

A moins que vous ayez une solution avec IN ou autre chose.

Bonne soirée

Bjr,

CITE: ...mais like ne permet pas la recherche de plusieurs mots dans plusieurs champs. ...

Il faut être très prudent avec le Like. En informatique, la technique qui est à la base de tout ça s'appelle 'patern matching' (cf: Knuth - Fundamental Algorithms/ The art of Programming)

Le 'patern matching' est très chronophage. Avec 20 à 100 enregistrements, vous ne verrez quasiment aucun effet sur l'exécution de la requête. Mais il existe un seuil qui dépend de divers paramètres au-delà duquel le temps d'exécution devient exponentiel par rapport au nombre d'enregistrements. C'est pourquoi il est impératif en amont de faire une pré-sélection.

Regardez un catalogue photos, genre Picasa ou Flickr, les photos peuvent être tagguées et les utilisateurs ne peuvent chercher QUE par ces mots clés.

Un exemple, vous avez des annonces, avant de filtrer dans le descriptif, il est nécessaire de restreindre la recherche à un type d'annonces et de lieux. sans quoi la base de données s'écroule et les délais d'exécution pénalisent TOUS les autres utilisateurs. Même dans un moteur de recherche les mots sont indexés dans un système d'indexation très complexe qui allie performance (arbres binaires balancés) avec une structure similaire au système ISAM des BDD comme mySQL.

En conclusion, ne faites pas faire à votre BDD des opérations trop complexes, ça a un coût. Sur un serveur mutualisé - du genre des hébergements gratuits FREE - le nombre de requêtes est déja limité dans un temps donné, mais si en plus elles sont chronophages, il y a une limitation en nombre de requêtes simultanées.

A+

Si le principal traitement qui est fait sur ta base consiste à faire des recherches de mots dans les champs, alors il serait plus opportun de créer une table qui contient les mots-clés que tu veux rechercher.
Cette table serait alimentée à la création d'un enregistrement 'principal' et elle y serait mise en relation en n,n.
En informatique, cela veut dire créer une table d'index...

Je suis sur un serveur virtuel.
Je sais bien que je dois limiter les requete et ce filtrage est ce que j'ai de plus lourd.

Je limite déjà la recherche sur des critères de choix que l'utilisateur aura coché pour déterminer ce qu'il veut chercher. En espérant qu'il coche et ne laisse pas vide.

Pour mes mots clé, ces denier sont enregistrés dans la même table que ces choix. Le filtrage est toujours sauvé avant d'être appliqué, dans une insertion lié a l'utilisateur via son "user_id".

Quoi qu'il en soit je ferais des test pour voir les lenteur et au besoin ajusterai en limitant le nombre de mots par exemple.

Mon problème reste entier sur la taille des requete.
Si j'ai bien compris je ne peux pas utiliser IN comme LIKE pour chercher des mots clé dans des champs vastes. Et je ne peux pas réduire la taille des requete avec IIKE comme c'est possible avec IN.

Merci de confirmer ou d'informer.
Bonne journée