sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : RE : [sdx-users] Performances


From: Martin Sevigny
Subject: RE : RE : [sdx-users] Performances
Date: Tue, 21 Jan 2003 09:21:41 +0100

Bonjour,

> Mais on ne peut trier _que_ sur les champs de type brief, 
> donc comment faire autrement?

Les champs "non brief" ne sont pas stockés par Lucene, alors on ne peut
faire autrement, effectivement. Mais la présence de ces champs n'est pas
catastrophique en terme de performances.

> C'est vrai que je mets aussi les "chapeau" en brief, qui sont 
> un résumé de chaque article, pour pouvoir les afficher dans 
> les résultats; y a-t-il une autre solution, qui consisterait 
> à inclure les chapeaux depuis un autre endroit de stockage, 
> seulement lorsqu'on affiche chaque page, au lieu qu'ils 
> soient présents en bloc dans l'ensemble du jeu de résultats ?

Pour cela, il y a à mon avis trois types de solutions :

1) Vous créer un champ (de type unindexed ou field), avec brief=true,
pour les afficher dans les résultats de recherche (je pense que c'est ce
que vous faites)

2) Dans les résultats de recherche, vous demandez à SDX non pas de
mettre des <sdx:field>, mais d'inclure carrément les documents trouvés
(quelque chose comme <sdx:execute*Query docs="true".../>)

3) Vous utilisez la fonction document() en XSLT pour inclure des
informations extérieures pour chaque résultat

La solution 1 est idéale lorsque la taille des champs brief est
nettement plus petite que la taille des documents originaux (je pense
que pour des articles ce sera le cas). La solution 2 est idéale dans le
cas inverse : si vous êtes en train de définir beaucoup de champs brief
au moint où tout votre document est en champ, alors c'est peut-être le
temps d'un docs=true! La solution 3 est plus difficilé à implanter et
suppose des informations externes.

A bientôt,

Martin Sévigny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]