SPSiteDataQuery vs. ricorsivo SPWeb.Lists prestazioni

Question

Sto cercando il miglior mezzo dello spettacolo di query per i dati del sito all'interno di una raccolta siti. Ho bisogno di query per tutti gli elenchi in entrambi un particolare SPWeb, o una serie di SPWeb di, che contengono un tipo di contenuto specifico. Il progetto su cui sto lavorando attualmente utilizza il codice come il seguente:

private void EnumerateChildWebs(SPWeb web, bool firstTime) {  
   if (!firstTime) {
      EnumerateListCol(web.Lists);
   }

   foreach (SPWeb child in web.Webs) {
      EnumerateChildWebs(child, false);
      child.Dispose();
   }
}

private void EnumerateListCol(SPListCollection spListCol) {
   SPList            list;
   SPContentTypeId   ctid;

   for (int i = 0; i < spListCol.Count; i++) {
      list = spListCol[i];

      if (list.ContentTypesEnabled && list.BaseType == SPBaseType.DocumentLibrary) {

         foreach (SPContentType ct in list.ContentTypes) {

            // [Omitted] - Code to check if the list contains a particular content type

            if (ct.ID matches the one we're looking for) {
               // Do something with the list
               break;
            }
         }
      }
   }
}

La mia domanda è, sarebbe generalmente meglio usare uno SPSiteDataQuery per fare questo? Sembra che produrrebbe codice più pulito tanto, ma per quanto riguarda le prestazioni? C'è qualche saggezza convenzionale intorno quando utilizzare SPSiteDataQuery? Ho letto alcune informazioni su di esso sul web, ma niente che indirizzi il mio scenario particolare.

Answer 1

Questo è uno scenario davvero interessante (e quello che ho guardato l'altro giorno), come non c'è molto supporto API per questo caso - la maggior parte dei metodi previsti sono circa elenco aggregazione oggetti piuttosto che liste stesse. Di conseguenza, se si tenta di utilizzare SPSiteDataQuery o uno degli approcci simili (ad esempio CrossListQueryCache) si può recuperare solo gruppi di risultati di oggetti , dal quale si sarebbe poi ricavare le liste controllanti - se questo sarebbe più efficiente di il vostro approccio attuale sarà probabilmente scenderà a quante elenco articoli sono interrogato / recuperati in questi gruppi di risultati 'intermedi'.

Se fai un'occhiata a questo approccio, trovare oggetti dove i ContentTypeID inizia con l'ID del sito tipo di contenuto appropriato è la query per utilizzare.

Il codice che stavo scrivendo l'altro giorno non era il codice di produzione, ma sono sicuro al 99% sono arrivato allo stesso risultato come si deve. Sia SPSiteDataQuery o simile fornirebbe una migliore performance potrebbe essere provata solo provandola nei nostri rispettivi siti penso, dal momento che il numero di liste / numero di voci di elenco / colonne indicizzate ecc sarebbero tutti fattori che avrebbero un grande impatto. Avendo <10 liste con <10 articoli ciascuno è chiaramente molto diverso dal 1000 liste con 100.000 articoli ogni.

P.S. Come riferimento generale sulle tecniche di aggregazione, i seguenti sono lettura interessante:

• http: //blog.mastykarz .nl / contenuti-query-web-parte-vs-custom-aggregazione-web-parte /
• http://blog.mastykarz.nl / prestazioni-di-content-aggregazione-query-on-multiple-lists /
• http://go.microsoft.com/fwlink/?LinkId=95450&clcid= 0x409 (di Steve Peschka di lavoro con grandi liste white paper)

Answer 2

Non sono sicuro se è applicabile qui, ma sul lato DVWP delle cose, c'è un DataSourceMode = "ListofLists" che ritorna, avete indovinato, una lista di liste. I servizi Web hanno funzionalità analoghe con la Lists.GetListCollection Metodo . Parto dal presupposto che, poiché questi due strati consentono di accedere alle informazioni sulle liste senza guardare a loro gli oggetti che l'API avrebbe fornito una funzionalità simile.