bonjour,
 
pour le site que je suis en train de réaliser, on m'a demandé de faire un moteur de recherche interne au site.
Celui ci permettrait de recenser des données qui se retrouvent dans mes champs d'une de mes tables de ma base de données  
Cependant, je ne veux pas créer une autre table où seront rentrées des mots clés....
Je sais pas si vosu m'avez compris mais voici un exemple :  
 
EXEMPLE:
 
   j'ai une table où sont rentré des incidents informatiques. mes utilisateurs peuvent consulter ces incidents selon le réparateur, la catégorie, la sous catégorie, le statut(en cours, clos, a traiter)(affichage sous forme d'un tableau)
   Ce moteur de recherche servira pour la sous categorie
   donc l'utilisateur tapera un mot clé(ex:pilote ou outlook....) et je voudrais que cela affiche les incidnets avec ces mots clés sous la meme forme que le tableau déjà établi.
________________________________________________________________________
 
j'ai essayé de chercher sur le net mais la plupart des liens que je trouve mettent en place une base de données avec des mots clés.
 
Si quelqu'un peut me donner des conseils, je suis a son écoute
 
a biento
 
merci....  

SELECT * FROM ma_table WHERE champ_incident LIKE '%mot_cle%'
 
Si je ne dis psa de bêtise...
 
++

Les tables myisam de mysql supportent les index fulltext. C'est le principe de la table de mots clefs en automatisé. Cependant, si tu ne peux pas toucher à la structure de ta base tu es condamné à faire des like comme explique par Dj YeLL, l'inconvénient c'est que c'est très lent.

 
en gros la tu me dis que je suis obligé de rajouter uen table avec des mots clés comme la plupart des moteurs de recherche?    
puis j'ai essayé de faire la requête je me doutais qu'il fallait faire comme ca, on me l'avait expliqué.Cependant, je ne vois pas trop où la mettre...
 
++
 
merci  

Via un formulaire tu définie $mot_recherche.

 
Je sais pas si c'est bien clair mais ca devrait aider je pense.
 
On va encore me dire "c'est du sql sur mysql et ya pas que mysql" je sais je sais je suis aussi pour la défense des autres SGBDR mais bon comme MySql est le plus répendu je pense qu'il fait de bon exemples. Après chacun son clan lol.

Il faut pas abuser non plus quand même c'est lent par rapport à la moyenne mais ca va pas durer 10 seconds quoi que ça dépend de la quantité de données mais il y a quand mêmes des petites astuces pour optimiser le résultat.

C'est ça, mais avec un index fulltext tu délègues tout à mysql.
Tuto : http://omiossec.developpez.com/mysql/fulltext/
La doc //dev.mysql.com/doc/mysql/fr/fulltext-search.html

Ouai mais bon en même temps si tu a déjà une BDD avec des tonnes de données, laisse tomber la création d'une nouvelle table et adopte le LIKE du sql qui rend certe la procédure plus lente mais ca reste tout a fait acceptable.

Je ne comprends pas pourquoi. Avoir des tonnes de données c'est justement une bonne raison pour créer un index !

Bon ok aprés ca depend du niveau du gars!
Maintenant reste à savoir si il est en mesure de créer un script pour indexer tout ca, parceque mauellement c'est quand même chaud..
 
En fait je me suis dit que vu les questions qu'il pose il ne devait pas avoir les compétances pour créer un tel script (ce n'est pas du tout un reproche).
 
Voila je reconnais que comme j'ai dit les choses ca apparaissait comme étant monumentalement con! lol

J'utilise pas ces index (cause innodb, je gère ça à la main ) mais il me semble qu'il suffi d'un "ALTER TABLE ... ADD FULLTEXT ..." pour en ajouté un.

Effectivement ouai.
Bon de toute facon c'est lui qui voit!

Merci pour votre attention je vais essayer tout ça....
a biento

C'est tout de même pas juste 'un peu lent' par rapport au reste, c'est excessivement lent, non ? Table scan et, pour chaque record, une recherche d'une sous-chaîne. Le genre de truc qui met la pression sur le système, potentiellement un single point of failure.
 
Tu penses à quelle astuce, dans le cas d'un LIKE %x% bête et méchant ?

J'ai pas lu le topic en détail mais je sais que nous avons recontré ce genre de problème dans mon ancienne boite. Nous avons fait un test sur une table de plusieurs méga.  
Test 1 : Demander a SQL de faire la recherche LIKE.
Test 2 : Retourner toute les informations et faire la recherche via php.
Au final c'est Test 2 qui a gagné. Pourquoi?  je ne sais pas cela m'étonne aussi !

euh....ca te derangeré de me donner la méthode stp lol
qu'est ce que tu appelle par retourner les informations?
tu peux me donner des pistes stp?
 
merci si tu le fais  
   

J'imagines qu'ils avaient fait un simple "select * from table".

Très étrange, mais je ne crois pas que cela soit généralisable !    
 
- Si le serveur PHP n'est physiquement sur la même machine que le serveur DB, le temps réseau prendra le dessus et la recherche PHP ne peut être que plus lente - je parie que les deux serveurs étaient sur la même machine lors de tes tests, ou bien étaient très "proches";
- Tu retournes potentiellement un nombre invraissemblable de lignes à PHP, alors qu'au final, il n'y a que peu de résultat. Si la bécane est déjà memory-bound, voire CPU-bound, ça va chier dans le ventilo et c'est chercher les ennuis;
- Ca se bouscule inutilement sur le rézo;
- Ton DBMS était peut-être anémique lors du test par rapport à un serveur PHP dopé aux hormones.
 
Mais ça prouve bien qu'il ne faut pas se fier aux a priori, et que rien ne remplace un benchmark!

 
2(cluster) x Quadruple CPU Intel 2Go MHz 4Go Ram. Bon j'avous que c'est pas une machine de surcouf. Nous avons utilisé des fonctions telle que mysql_unbuffered_query() qui est reduit de pas mal la charge mais il ne faut pas l'utiliser n'importe comment.  
Ha j'ai oublié un truc, c'est à refroidissement liquide !

Je le savais