Re: [sdx-users] simpleQuery / complexQuery: performances?

[Pierrick Brihaye]

Re,

> > En mentionnant un champ dans une simpleQuery, vous ne faites que
> > spécifier le champ de recherche *par défaut*... si un utilisateur entre
> > un_champ:blabla, la recherche s'effectuera sur le champ un_champ.
>
> Oui, et je trouve ça très bien ! ;-)

Puisqu'on est dans les goûts et les couleurs, voici comment je vois les
choses :

1) une recherche "simple" doit se faire sur un petit nombre de champs,
idéalement un... le champ fulltext. On a donc une FieldQuery. Autant que
faire se pourra, les champs seront de type "word" sinon, l'utilisateur sera
dérouté par des exigences aussi sévères.

2) ensuite, on aborde les recherches "assistées" avec liste de champs et,
pour les champs de type "field", déventuelles listes d'autorités. Là encore,
on a des FieldQuery IMHO.

3) pour terminer, on a la véritable recherche avancée, destinée aux
utilisateurs qui connaissent à la fois la strcuture d'indexation et les
valeurs cherchables dans les index. Ici, la requête idéale est... la
SimpleQuery :-) Bien sûr, il faut que le langage de requête reste simple :
c'est pour cela que je pense qu'un soin tout particulier doive être porté
aux QueryParser ; les récents développements avec le "délimiteur de valeur"
("|") vont dans ce sens IMHO.

En ce qui concerne une l'interface, je reconnais qu'il n'est pas simple
d'utiliser FieldQuery pour faire une recherche croisée, mais bon, on peut
aussi réutiliser des requêtes existantes pour les affiner... ou parser un
paramètre unique en autant de valeurs qu'il y a de "tokens" (la notion de
token étant fortement tributaire du design que l'on veut donner à l'appli ;
apparement un mot dans votre cas)... puis de les injecter dans autant de
FieldQuery.

Mes 2 centimes...

A+

p.b.