Discussion :

[zanteskuken]

Bonjour à tous

Je développe un autocomplete dans le but d'afficher une liste de résultats selon saisie et aimerai mettre en place une règle de recherche sur la saisie.

Explication :

Je souhaite récupérer comme valeur, par exemple, "Pré-station"

Quelque soit le cas où l'utilisateur taperai "Pré" ou "pré" ou "pre-" ou "pre stati" ou "pre-s" etc

Quel devrai être le genre de ma requête ?

(ma base est sur mysql 5.5)

J'ai actuellement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Select ..... where name like 'paramètre%';

Qui ne convient donc pas suffisamment donc.

Si je tape "Bré" J'aurai en résultat par exemple, "Bré-reatic"
Si je tape "Bré reactic", je n'ai rien en résultat
Si je tape "Bre-r", j'ai "Bré-reactic"

1 - je ne sais qui (langage) est comment, mon 'e' de "Bre-r" et bien reconnu en 'é' pour le résultat "Bré-reactic" (oui j'aimerai bien savoir ).
2 - Comment prendre en compte l'ensemble de la saisie "Bré reactic" pour qu'il soit bien associé à celui de "Bré-reatic" recherché.

Le "-" pouvant aussi bien être ' ou `par exemple.

J'ai essayé un test regexp du genre (mais c'est long en temps de requête)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 where name regexp 'Bre- | Bre`| Bre' '

J'ai vu quelques part l'idée d'un index FullText mais ma table est innodb (j'utilise des clé étrangère pour mes jointures et j'ai cru comprendre que MyIsam aimé pas ça).

Si vous auriez des pistes avec l'idée de souci de performances bien sur

Merci

Ps : J'ai un index sur la colonne dont je fais la recherche bien sur et cette colonne et de type varchar utf8-unicode-ci

[Exia_]

Bonsoir,

pour ta première question la recherche avec LIKE est insensible à la casse donc si dans ta colonne est stocké le mot Test une recherche avec le mot clé test ou TEST ou tEsT fonctionnera et idem pour les accents si tu fait une recherche avec le mot clé TêSt l'enregistrement sera retourné.

Pour ta seconde question la solution aurait été de passer par la fonction MATCH() AGAINST() qui utilise un index full text seulement InnoDB ne gère pas cet index, donc si tu peut convertir ta table en MyISAM je pense que sa serait la meilleur solution.

[zanteskuken]

Merci Exia93

D'accord je comprends mieux pour la première question, merci.

Pour la deuxième, zut zut, c'est ce que je pensais mais j'espérais une alternative.

En revanche, juste avant de lire ton message, j'ai lu une note sur le forum spécifiant que la version mysql 5.6 permettrai (billet datant de fin 2011-debut 2012) et donc permet peut-être actuellement, une indexation de type Full-Text sur une table InnoDB.

ça à l'air d'être le cas ici. Il me faudra essayer alors et trouver un tuto pour migrer.

En fait MyIsam ne pense pas me correspondre car j'utilise des clés étrangères pour accélérer les jointures entre tables lors de mes recherches et retour de résultats (joins) et j'ai lu quelques par que MyIsam ne géré pas les clés étrangères.

Merci de ta réponse Exia93

[punkoff]

pour ta première question la recherche avec LIKE est insensible à la casse donc si dans ta colonne est stocké le mot Test une recherche avec le mot clé test ou TEST ou tEsT fonctionnera et idem pour les accents si tu fait une recherche avec le mot clé TêSt l'enregistrement sera retourné.

euh ... je regarderai la collation de votre base où vous avez fait le test avant de dire ça. http://dev.mysql.com/doc/refman/5.0/...nsitivity.html


Sinon une autre solution serai de stocker, dans une autre colonne, vos chaine dépourvu de tous caractères spéciaux

[zanteskuken]

euh ... je regarderai la collation de votre base où vous avez fait le test avant de dire ça. http://dev.mysql.com/doc/refman/5.0/...nsitivity.html


Sinon une autre solution serai de stocker, dans une autre colonne, vos chaine dépourvu de tous caractères spéciaux

Bonjour et merci de ce retour.

J'ai regardé le lien que vous avez stipulé. D'accord, vous voulez parler du type d'encodage "sensitive" qui est sensible à la casse.

Tout mes types sont insensible à la casse, étant donné que je veux justement récupérer des données selon cette idée. ils sont donc sous collation "utf8_unicode_ci"

Pour l'autre remarque, cela ne conviendrai. Je veux justement pouvoir les reconnaitre.

Cela me ferai de la perte d'information ou je n'ai pas saisie.

Si j'ai une table du style :

rolland
jean-jacques
hervé

Vous me conseiller d'avoir
Table 1
Rolland

Table 2
jean-jacques
hervé

quel serai le but ?
Sachant que je veux retrouver 'jean-jacques' si un utilisateur tape 'jean jacques'.

Ceci est un exemple, l'idée concrète et de pouvoir retrouver le nom d'une ville, qui peut-être donc connu sous différents noms et avec donc des caractères très spéciaux.

ex : namecity (text) = Venise-en-velay, Venezia en velto, Veñesia, Vénetia

Si on tape venesia-en, j'aurai "Veñesia en velto"

(je bute sur un autre souci, je ferai un autre billet)

[SQLpro]

MySQL gère très mal les collations (ce n'est d'ailleurs pas la seule chose qu'il fait mal... A lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux)
Sur ce sujet : http://blog.developpez.com/sqlpro/p1..._grand_folklor
Si il les gérait bien, comme par exemple MS SQL Server, il aurait simpluement suffit de préciser dans votre recherche LIKE : COLLATE French_CS_AS (ce qui veut dire, utilise un comparaison sensible à la casse (CS) et sensible aux accents (AS)

A +

[zanteskuken]

Cela semble dépitant donc.

J'ai lu rapidement ce très long article où mysql semble très fustigé. Il me faut déprimé ou.. . Je n'ai aucune connaissance à tirer un pour ou contre de l'ensemble annoncé. La conclusion effraierai donc ma peine à désirer une compréhension de tout caractère par ma table.

MS sql server n'est pas sous licence gratuite et je n'ai pas d'argent...

LIKE : COLLATE French_CS_AS

Intéressant à savoir.

Pour mon cas cela ne suffit, j'ai des données en toute langues.

1 - Avec ce que j'ai actuellement je peu gérer (via mysql)

-> les Majuscules/Minuscules et les accents aiguës, graves, tildés

Exemple : "veñise" me donne bien "Venise".

L'idée bien sur et de parer différentes écritures internationales ou voir même petites fautes. Cela me conviens assez pour le moment.

Je voulais juste pouvoir récupérer "Saint-Denis" si je tape "Saint denis".

Le "tiret" est un caractère spécial et pas un accent.

2 - J'ai testé le "FUll_index" (testé est un bien grand mot bien sur).

@Exia93 : Cela à bien pris en considération le tiret en effet, merci d'avoir palier à me demande. Je tape "saint denis" et j'ai "Saint-Denis".

Nb : je n'ai pas le créé via la fenêtre structure de phpmyadmin, j'ai du effectuer une requête moi même "create fulltext etc..." (j'ai une version ancienne de phpmyadmin qui doit être dû (3.5 au lieu de 4. actuellement) )

En revanche, je remarque ceci :

Avec un index "normal" en tapant
: 't za -> j'avais en résultat 't Zandt

Avec un fullText
: 't za -> Je n'ai rien

Je dois aller jusqu'à 't zandt

La " simple quote" semble un peut être zappé.

Auriez-vous noté ce genre de chose ? ou me diriez-vous "on ne peut pas tout avoir", ce que je comprendrai.

3 - @SqlPro : Merci de vos sujets, qui m'alertent en effet et ne sais plus quoi penser.

Il est certains que si mes données ne sont bien reconnu, leur recherche (requête) pourraient donc être faussées, si j'ai bien compris. De plus que vous semblez préciser que les index sont mal conçus, manque d'indexage voir perte de données (si j'ai bien lu vite fait), appuyant aussi sur le point de la concurrence des requêtes (supérieur à 5 cela se complique), chose que je ne souhaite pas du tout.

Comment en être arrivé là...

Postgresql conseillez-vous donc. Je fus parti sur la version 9.0 puis on m'incita à mysql (plus rapide il parait).
Mon besoin serai celui de beaucoup pourtant, celui de concurrence haute, de recherche rapide, d'intégrité de donnée multilingue.

C'est assez complexe tout ceci en effet. Que penser lorsque j'entends sur des forums "le Fulltext index consomme beaucoup en mémoire, risque à saturation de la mémoire server et 'crash' ". Je ne le souhaite du tout surtout que je n'aurai de super mega center juste un petit server donc vaut mieux bien programmer ; ) .

Toujours trébucher après le prochain pas.

Postgresql ferai tout pareil en mieux ? qui l'assurerai (tout le monde se contredisant) ? Comment un non expert comme moi peut s'en sortir du coup .

En d'autre termes mon application viserai toutes les contraintes que vous pourrez retrouver sur un "site de rencontre" (affluence, rapidité, internationalisation des données, stockage, notifications, etc), dans un autre domaine, pourtant bien nombre d'entre eux sont sur mysql non ? comment font-ils ? Je reste perdu un peut.

[SQLpro]

MS sql server n'est pas sous licence gratuite et je n'ai pas d'argent...

FAUX : il existe plusieurs éditions gratuites de SQL Server, certes limitée : SQL Server Express et je vous conseille la version Advanced dans votre cas, qui inclue Reporting Services et bian d'autres choses...
Les limitations sont :
1) base de moins de 1 Go (mais au plus 32 000 bases, soit 320 To)
2) RAM utilisé par SQL Server Express (moins de 1 Go), mais possibilité de monter plusieurs instances (50 au maximum)
3) un seul CPU à 4 core utilisé (mais avec plusieurs isntances ont peut croiser l'utilisation des CPU)

En sus, vous pouvez utiliser la version Azure (cloud) qui vous assure l'hébergement machine + SQL Server "full power" à un prix modique basé sur votre utilisationn des données (et en plus la partie haute dispo est assurée naturellement...).

Intéressant à savoir.

Pour mon cas cela ne suffit, j'ai des données en toute langues.

Dans ce cas SQL Server est le seul SGBDR à supporter quasiment toutes les langues de la planète... Oracle en comparaison fait beaucoup moins bien ! Voici la liste des langues supportées via les collations :

• Albanian
• Arabic
• Assamese
• Azeri
• Bashkir
• Bengali
• Bosnian
• Breton
• Chinese
• Corsican
• Croatian
• Cyrillic
• Czech
• Danish
• Dari
• Divehi
• Estonian
• Finnish
• French
• Frisian
• Georgian
• German
• Greek
• Hebrew
• Hungarian
• Icelandic
• Indic
• Japanese
• Kazakh
• Khmer
• Korean
• Lao
• Latin1
• Latvian
• Lithuanian
• Macedonian
• Maltese
• Maori
• Mapudungan
• Modern
• Mohawk
• Nepali
• Norwegian
• Pashto
• Persian
• Polish
• Romanian
• Romansh
• SQL
• Sami
• Serbian
• Slovak
• Slovenian
• Syriac
• Tamazight
• Tatar
• Thai
• Tibetan
• Traditional
• Turkish
• Turkmen
• Uighur
• Ukrainian
• Upper
• Urdu
• Uzbek
• Vietnamese
• Welsh
• Yakut
  
  Vous aprécierez j'en suis sûr le Breton et le Corse !

1 - Avec ce que j'ai actuellement je peu gérer (via mysql)
-> les Majuscules/Minuscules et les accents aiguës, graves, tildés
L'idée bien sur et de parer différentes écritures internationales ou voir même petites fautes. Cela me conviens assez pour le moment.
Je voulais juste pouvoir récupérer "Saint-Denis" si je tape "Saint denis".
Le "tiret" est un caractère spécial et pas un accent.
2 - J'ai testé le "FUll_index" (testé est un bien grand mot bien sur).
@Exia93 : Cela à bien pris en considération le tiret en effet, merci d'avoir palier à me demande. Je tape "saint denis" et j'ai "Saint-Denis".
Nb : je n'ai pas le créé via la fenêtre structure de phpmyadmin, j'ai du effectuer une requête moi même "create fulltext etc..." (j'ai une version ancienne de phpmyadmin qui doit être dû (3.5 au lieu de 4. actuellement) )
En revanche, je remarque ceci :
La " simple quote" semble un peut être zappé.
Auriez-vous noté ce genre de chose ? ou me diriez-vous "on ne peut pas tout avoir", ce que je comprendrai.

Il y a bien d'autres surprises dans la MySQL au sujet du Full Text... Dans mon livre sur la langage SQL j'ai fait une comparaison sur ce que la norme SQL propose et sur ce que font MySQL et SQL Server.... Vous pouvez en avoir un extrait dans cet article... mais le pire est que MySQL n'indexe pas les mots de moins de 4 lettres... Je me souviens qu'un site Web avait voulu utiliser MySQL pour des annonces de voiture... catastrophe toutes les requêtes portant sur Peugeot 205, Mercedes 220, Renault R6... ne remontaient rien d'utile... Bref panique à bord et changement de serveur dans l'urgence à quelques semaine de la mise en prod !!!! Merci MySQL

3 - @SqlPro : Merci de vos sujets, qui m'alertent en effet et ne sais plus quoi penser.

Il est certains que si mes données ne sont bien reconnu, leur recherche (requête) pourraient donc être faussées, si j'ai bien compris. De plus que vous semblez préciser que les index sont mal conçus, manque d'indexage voir perte de données (si j'ai bien lu vite fait), appuyant aussi sur le point de la concurrence des requêtes (supérieur à 5 cela se complique), chose que je ne souhaite pas du tout.

Comment en être arrivé là...

Postgresql conseillez-vous donc. Je fus parti sur la version 9.0 puis on m'incita à mysql (plus rapide il parait).

Légende urbaine... Montrez moi des benchmark... La pauvreté de MySQL montre l'inverse. Le fait d'entre être resté au SQL de la norme de 1992 (soit plus de 20 ans de retard par rapport à la concurrence) se paye très cher sur des requêtes complexes comme je l'ai démontré ici : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
On y voir juste que MySQL est 1000 fois plus lent que SQL Server et PostGreSQL 10 fois plus lent. En sus l'écart s'est récemment comblé et PostGreSQL et MS SQL Server sont maintenant à même niveau.

Mon besoin serai celui de beaucoup pourtant, celui de concurrence haute, de recherche rapide, d'intégrité de donnée multilingue.

Toutes chose pour laquelle MySQL est catastrophique : la concurrence est tellement mal gérée dans MySQL qu'à plus de 10 utilisateurs ça se casse la gueule...(le problème est que certains imbéciles nous montre des comparaisons avec 1 ou 5 user en // pour favoriser MySQL.. Or justement MySQL plonge à partir de 10... Comme cet article... or dans la réalité si vous n'avez que 5 users, autant prendre du Access !!! En comparaisons, SQL Server est utilisé par fnac.com, cdiscount ou ventre-privées en France, avec plsueiurs milliers d'utilisateurs simultanés...) Les contraintes CHECK n'existent toujours pas sous MySQL, l'indexation est pauvre et mal conçue et ça c'est indispensable pour les recherches rapides (voire la comparaison que j'ai fait ici sur les technique d'indexation :
http://blog.developpez.com/sqlpro/p9...ut_sur_l_index )....

C'est assez complexe tout ceci en effet. Que penser lorsque j'entends sur des forums "le Fulltext index consomme beaucoup en mémoire, risque à saturation de la mémoire server et 'crash' ". Je ne le souhaite du tout surtout que je n'aurai de super mega center juste un petit server donc vaut mieux bien programmer ; ) .

C'est tout à fait vrai... Et dans MySQL c'est très très mal géré; En effet, c'est synchrone dès que vous insérez des données. par exemple si vous faites un import de données conséquent. mettons 10 000 lignes, alors MySQL va mouliner pendant des heures pour créer l'index textuel. En comparaisons, SQL Server le fait en mode asynchrone et à votre choix : au fil de l'eau (tache d'arrière plan) ou planifiée (par exemple lanuit) en mode différentiel (journalisation des nouvelles entrées) ou en mode scratch (l'index est reconstruit en intégralité). En sus dans SQL Server il est possible de régler la bande passante de la tâche d'arrière plan, de façon à lui limiter les ressources afin qu'elle ne pénalise jamais la production... Bref, rien à voir avec cet ersatz de SGBD qu'est MySQL !

Toujours trébucher après le prochain pas.

Postgresql ferai tout pareil en mieux ? qui l'assurerai (tout le monde se contredisant) ? Comment un non expert comme moi peut s'en sortir du coup .

Ce que je dit à mes étudiants : tester, tester, tester... mais en vrai grandeur : au moins 100 000 lignes dans chaque table, au moins 30 utilisateurs, sinon 100 simultané, sinon, cela ne veut rien dire !

En d'autre termes mon application viserai toutes les contraintes que vous pourrez retrouver sur un "site de rencontre" (affluence, rapidité, internationalisation des données, stockage, notifications, etc), dans un autre domaine, pourtant bien nombre d'entre eux sont sur mysql non ? comment font-ils ? Je reste perdu un peut.

Non, le "je suis sur MySQL est marketing".... Il ne sert qu'au stockage de certaines données non relationnelles. Par exemple le site d'annonce de "le bon coin" est sur postgreSQL..., MySpace est sur SQL Server; Des sites comme linkedin ou viadeo utilisent du noSQL, car pas besoin de transactions....

A +

[zanteskuken]

Bonjour !

Merci pour votre explicite retour bien structuré, c'est très appréciable. Vos étudiants doivent en être autant appréciés.
J'eus bien lu vendredi dernier votre poste et répond en ce jour pour ne pas avoir de retour trop hâtif.

Oui en effet, il y a deux versions gratuites de SQL Server 2012.

Personnellement j'ai beaucoup de mal à trouver les grandes lignes de ce qu'offre SQL Server 2012 , microsoft présente trois groupes d'éditions Standart/Entreprise/BI avec de Très Très Très grande lignes. Des grandes lignes auraient été préférable (ici on peut toutefois dl un tableaux comparatif).
Il est certain qu'a mes yeux "une puissance" de sql server est le panel d'outils intégrés permettant la gestion du server, une sorte de "tout en un".

Les limitations sont :
1) base de moins de 1 Go (mais au plus 32 000 bases, soit 320 To)
2) RAM utilisé par SQL Server Express (moins de 1 Go), mais possibilité de monter plusieurs instances (50 au maximum)
3) un seul CPU à 4 core utilisé (mais avec plusieurs instances ont peut croiser l'utilisation des CPU)

Je confirme.
C'est marqué 1Go de Ram Bdd sur le tableau.
J'ai bien compris l'idée émise mais d'instinct je ne m'y risquerai pas.
1- Je ne suis IT server
2- Je ne connais pas sql server (je ne fais que de l'autodidacte)
3- je ne connais aucune notion de reporting et si tant d'autre concept d'analytique et gestion à plus haut niveau de base.

Ma bd avant production sera de 1go sans doute. Jouer avec plusieurs base ? Recherché une ligne dans bdd1, puis dans Bdd2 si pas présente, etc. Après on peut inventer des idées : bdd1 de "A" à "M" et bdd2 de "N" à "Z".
Plusieurs instance pour augmenter la capacité ram de la bdd semble du tricotage qui m'effraie n'ayant cet expertise. Idem pour CPU.

L'idée de cette version est bien sur de pousser l'utilisateur à prendre la complète pour avoir moins de problème de Maintenance !!! Excusez ma frilosité.

Sql server est trop prématuré pour moi. Il m'est plus judicieux de partir "ligth" et si l'application fonctionne je "boosterai" le serveur. C'est ce que je me dis à priori.

Dans ce cas SQL Server est le seul SGBDR à supporter quasiment toutes les langues de la planète... Oracle en comparaison fait beaucoup moins bien ! Voici la liste des langues supportées via les collations :

Je ne veux pas faire de restriction sur langues à travers des dictionnaires, c'est plutôt l'idée inverse, "universel", utf8 à collation unicode sans casse. Taper n'importe quoi dans n'importe quel langue, i.e., caractère (donc un tableau ascii le plus complet possible d'où utf8) et que la recherche plein texte gère bien l'insensibilité à la casse (Maj/Min/accent).

Ex : si je comprends bien, si je mets une collation Breton, un mot en espagnole "vañina" ne sera pas reconnu de par le caractère (~) inconnu dans le dictionnaire Breton. Ce qui n'est pas désiré. Si je ne me trompe pas.

Vous aprécierez j'en suis sûr le Breton et le Corse !

Même pas le Ch'ti !!!

Légende urbaine... Montrez moi des benchmark...

L'Atlantide, le gouffre du diable, le monstre du loch ness, tout ceci serai faux ???

Justement, je me fie sur les benchmark d'autrui n'ayant l'atout de le faire moi-même.

J'ai lu vos différents article cité en lien et personne ne semblais contredire vos sujets, reflétant sans doute une bonne appréciation.

En comparaisons, SQL Server le fait en mode asynchrone et à votre choix : au fil de l'eau (tache d'arrière plan) ou planifiée (par exemple lanuit) en mode différentiel (journalisation des nouvelles entrées) ou en mode scratch (l'index est reconstruit en intégralité). En sus dans SQL Server il est possible de régler la bande passante de la tâche d'arrière plan, de façon à lui limiter les ressources afin qu'elle ne pénalise jamais la production...

C'est bien vous répondez à une question que je n'ai posé. Justement je m'étais déjà dis que je devrais couper le server pour faire des mises à jour deux fois par an. Une notion en arrière plan que j'aurai préféré.

En effet, je n'ai pas essayé sql server, mais j'ai créé un index su mysql et ça prend du temps, je ne sais plus si s'en était autant sur postgresql. Puis FullText d'un coté (mysql) et tsvector de l'autre (pgsql) sur 7M de lignes et c'est long.. Fin je ne comprends pas qu'il n'y ais pas un outils pour effectuer ce genre d'opération sans bloquer une production.
La différence est sans doute que sql server englobe des outils pour gérer le server et le sgbdr. Mais il y a peut-être aussi des outils plus haut niveau pour palier aussi ceci sur pgsql par ex.

Par exemple le site d'annonce de "le bon coin" est sur postgreSQL..., MySpace est sur SQL Server

Je suis entre les deux, quel coïncidence...

L'idée d'internationalisation comme le site couchsurfing (dont je viens d'ailleurs de retourner voir et pfuii, il à bien changé !!!) et la forte demande d'un site comme le bon coin. Oui voila, c'est marrant ça, j'ai lu la semaine dernière au hasard, un article sur leboncoin sur le site "le jdn" qui stipulé qu'ils avaient migré leur base de mysql à postgresql avec leur 80 000 E/S sur la bdd et les 200 000 nouvelles annonces par jour (wha c'est énorme, tout le monde à un magasin chez soi ?? ).
Si leboncoin peut le faire je le peut aussi alors hé hé.

Voila, mon besoin est la fusion des deux sites, à méditer. pgsql pas assez suffisant ? sql server trop compliquer ? les deux questions à réfléchir.