Per eseguire ricerche nei dati in un sito di SharePoint, è possibile usare due web part. Sono molto simili: la web part Query contenuto e la web part Ricerca contenuto. Semplicemente osservando i loro nomi, non è chiaro distinguere la differenza tra i due.
Nella maggior parte dei casi è consigliabile usare la web part Ricerca contenuto perché non influisce sulle prestazioni tanto quanto sulla web part Query contenuto.
È importante comprendere i punti di forza e le limitazioni delle due web part. Nella maggior parte dei casi è consigliabile usare la web part Ricerca contenuto perché non influisce sulle prestazioni tanto quanto sulla web part Query contenuto.
-
Usare la CQWP quando si ha una quantità limitata di contenuto, la query è semplice e non si prevede che il contenuto aumenterà molto in futuro.
-
Usare la web part Ricerca contenuto in tutti gli altri scenari quando si vuole visualizzare il contenuto basato su una query.
La tabella seguente fornisce un confronto tra le due web part:
|
Comportamento delle web part |
Web part Query contenuto |
Web part Ricerca contenuto |
|---|---|---|
|
Configurazione query |
Facile |
È necessario conoscere alcune caratteristiche di ricerca, ad esempio Gestire lo schema di ricerca in SharePoint Online. |
|
Eseguire query su grandi quantità di contenuto |
Limitata |
Sì |
|
Gestire query complesse |
Limitata |
Sì |
|
Ridimensionare per gestire la crescita futura del contenuto |
Limitata |
Sì |
|
Visualizzare il contenuto di altre raccolte siti |
No |
Sì (vedere Usare la web part Ricerca contenuto per visualizzare il contenuto di un'altra raccolta siti di seguito) |
|
La struttura dei risultati della query può essere personalizzata |
Sì, usando XSLT. |
Sì, tramite HTML. |
|
Costi di manutenzione in un'architettura del sito complessa |
Alto |
Piccola (vedere Usare la web part Ricerca contenuto per mantenere i costi di manutenzione inferiori ) |
|
Limitare i risultati della query visualizzati nella web part |
No |
Sì, in combinazione con la web part di perfezionamento. |
È possibile usare entrambe le web part per visualizzare informazioni archiviate in un sito secondario. L'esperienza utente per gli autori di contenuto e i visitatori del sito iniziale è identica, indipendentemente dalla web part in uso. La differenza tra le due web part è la tecnologia usata dalle web part. La web part Ricerca contenuto esegue una query su un database, mentre la web part Ricerca contenuto esegue una query sull'indice di ricerca.
Ecco un esempio di comportamento di queste web part. L'esempio A mostra una società che usa una web part Ricerca contenuto per visualizzare il contenuto del relativo sito secondario di vendita, mentre l'esempio B mostra una società che usa una web part Ricerca contenuto per visualizzare il contenuto del relativo sito secondario di vendita.
|
Callout immagine |
Esempio A: |
Esempio B: |
|---|---|---|
|
1 |
Si crea contenuto in un elenco. |
Si crea contenuto in un elenco. |
|
2 |
Le voci di elenco vengono archiviate immediatamente in un database. |
A un intervallo di tempo impostato, le voci di elenco vengono automaticamente sottoposte a ricerca per indicizzazione e aggiunte all'indice di ricerca. |
|
3 |
Un visitatore visualizza il sito iniziale. Il CQWP ha rilasciato automaticamente una query al database. |
Un visitatore visualizza il sito iniziale. La web part Ricerca contenuto invia automaticamente una query all'indice di ricerca. |
|
4 |
Il database restituisce un risultato della query e lo visualizza nella web part Ricerca contenuto. |
L'indice di ricerca restituisce un risultato della query e lo visualizza nella web part Ricerca contenuto. |
Poiché le web part usano tecnologie diverse, i casi d'uso in cui è consigliabile scegliere una web part rispetto all'altra sono diversi. Un caso d'uso è spesso più complesso del semplice esempio illustrato nella sezione precedente. Prima di decidere quale web part usare, è importante considerare quanto segue:
-
Qual è la quantità di contenuto disponibile?
-
Quanto sarà complesso per query?
-
Dove verranno archiviati i miei contenuti?
-
Quanto crescerà il contenuto nel corso del tempo?
-
Quanto cresceranno i costi di manutenzione nel tempo?
È consigliabile rivolgersi a tutte queste aree nel suo complesso anziché separatamente.
Nota: Se si prevede di passare da un sito di SharePoint locale a un sito di SharePoint Online e si usa Call Quality Dashboard nel sito locale di SharePoint, potrebbero verificarsi un paio di problemi di prestazioni. In SharePoint Online non sarà possibile ridimensionare il tenant per migliorare le prestazioni. Inoltre, il comportamento della funzionalità di memorizzazione nella cache è diverso in SharePoint Online rispetto a SharePoint locale.
Effetti sulle prestazioni della web part Query contenuto
Nell'esempio precedente, se l'elenco Notizie contiene meno di 5.000 elementi, è probabile che le prestazioni della web part Ricerca contenuto siano molto buone. Tuttavia, se l'elenco Notizie supera i 5.000 elementi e la query nella web part Call Quality Dashboard è complessa, la web part può riscontrare problemi di prestazioni. È difficile definire esattamente cos'è una query complessa, ma un'origine che attraversa tutti i siti della raccolta siti è più complessa di un'origine che esegue una query su un elenco specifico. Inoltre, se la query usa Filtri aggiuntivi, la complessità della query aumenta. La complessità delle query aumenta a seconda dei tipi di colonna del sito e delle condizioni usate. Ecco alcuni esempi:
-
Una query che filtra in base a una colonna del sito di tipo Più righe di testo è più complessa di una query che filtra in base a una colonna del sito di tipo Sì/No.
-
Un filtro che usa una condizione contenente è più complesso di una query che usa una condizione è uguale a.
-
Più condizioni O aumenta la complessità della query.
Le prestazioni della web part Ricerca contenuto sono influenzate anche dalla posizione in cui è archiviato il contenuto. Se il contenuto è archiviato in più siti, le prestazioni saranno influenzate dalla quantità totale di elementi di elenco che la web part deve elaborare. Ad esempio, nel sito iniziale della società si vogliono visualizzare le notizie più recenti provenienti da elenchi gestiti in più siti secondari. Ogni elenco contiene 1000 elementi. Questo significa che il CQWP dovrà eseguire query su 3000 elementi.
In questo esempio, se la query è semplice, è probabile che le prestazioni della web part Ricerca contenuto siano buone, purché la quantità totale di elementi sia inferiore a 5000. Tuttavia, se la query è complessa, il CQWP potrebbe riscontrare problemi di prestazioni anche quando la quantità totale di elementi è di poche migliaia.
Un altro fattore importante che può influire sulle prestazioni della web part Ricerca contenuto è l'aumento del contenuto. Una soluzione che oggi funziona bene potrebbe non essere applicabile ai tuoi contenuti futuri. Se si prevede un notevole aumento del numero di siti o della quantità di contenuto, non è consigliabile usare la web part Ricerca contenuto.
È possibile usare entrambe le web part per visualizzare il contenuto in base alle informazioni della struttura di spostamento del sito. Ad esempio, quando un visitatore accede a una pagina, la web part nella pagina invia automaticamente una query che contiene informazioni dalla struttura di spostamento del sito. I risultati della ricerca vengono visualizzati nella web part. Se non si ha molto contenuto e la query è semplice, è possibile usare più call quality dashboard per visualizzare il contenuto. Tuttavia, poiché è necessario mantenere ogni CQWP singolarmente, i costi di manutenzione possono aumentare rapidamente.
Usando la web part Ricerca contenuto con l'esplorazione gestita e una pagina di categorie, i costi di manutenzione rimarranno gli stessi dell'aumento del contenuto. Ad esempio, se si aggiunge una nuova categoria di spostamento al contenuto, è possibile usare la stessa pagina di categorie per visualizzare il contenuto che appartiene alla nuova categoria di spostamento. Quindi, anche se il contenuto è in crescita, è sufficiente mantenere lo stesso numero di pagine.
Per altre informazioni, vedere questi articoli aggiuntivi:
Nell'esempio seguente è possibile vedere in che modo quattro web part Ricerca contenuto possono essere sostituite da una web part Ricerca contenuto in una pagina di categorie.
È possibile usare la web part Ricerca contenuto per visualizzare il contenuto di altre raccolte siti. Ad esempio, se si vuole creare contenuto in una raccolta siti e visualizzarlo in un'altra raccolta siti, è necessario usare la web part Ricerca contenuto. La web part Ricerca contenuto può visualizzare il contenuto di una sola raccolta siti.
Se non si è certi della web part da usare, la web part Ricerca contenuto è probabilmente la scelta migliore nella maggior parte dei casi. Questa web part è più flessibile rispetto alla web part Call Quality Dashboard e offre prestazioni migliori se si prevede di espandere il contenuto nel tempo.
Se si decide di usare CQWP, è consigliabile eseguire test per scoprire se la web part soddisfa i requisiti di prestazioni e manutenzione attuali e futuri.
