SPSiteDataQuery противРекурсивная производительность SPWeb.Lists

Question

Я ищу наиболее эффективные средства запроса данных сайта в семействе сайтов.Мне нужно запросить все списки либо в определенном SPWeb, либо в наборе SPWeb, которые содержат определенный тип контента.Проект, над которым я работаю в настоящее время, использует код, подобный следующему:

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;
            }
         }
      }
   }
}

Мой вопрос в том, было бы вообще лучше использовать SPSiteDataQuery для этого?Кажется, что это дало бы гораздо более чистый код, но как насчет производительности?Существует ли какое-либо общепринятое мнение о том, когда следует использовать SPSiteDataQuery?Я прочитал некоторую информацию об этом в Интернете, но ничего, что касалось бы моего конкретного сценария.

Answer 1

Это действительно интересный сценарий (и тот, который я рассматривал на днях), поскольку в API для этого случая не так много поддержки - большинство предоставляемых методов касаются агрегирования списка Товары вместо того, чтобы перечислять самих себя.Следовательно, если вы попытаетесь использовать SPSiteDataQuery или один из подобных подходов (напримерCrossListQueryCache) вы можете извлекать наборы результатов только из Товары, из которого вы затем извлекли бы родительские списки - будет ли это более эффективным, чем ваш существующий подход, скорее всего, зависит от того, сколько элементов списка запрашивается / извлекается в этих "промежуточных" наборах результатов.

Если вы посмотрите на этот подход, поиск элементов, в которых ContentTypeID начинается с соответствующего идентификатора типа контента сайта, является используемым запросом.

Код, который я писал на днях, не был производственным кодом, но я на 99% уверен, что пришел к тому же результату, что и вы.Я думаю, что вопрос о том, обеспечит ли SPSiteDataQuery или аналогичный более высокую производительность, может быть доказан только путем тестирования его на наших соответствующих сайтах, поскольку количество списков / количество элементов списка / индексированных столбцов и т.д.все это были бы факторы, которые оказали бы большое влияние.Имея < 10 списков с < очевидно, что по 10 пунктов в каждом сильно отличаются от 1000 списков по 100 000 пунктов в каждом.

P.S.В качестве общей ссылки на методы агрегирования интересно прочитать следующее:

• http://blog.mastykarz.nl/content-query-web-part-vs-custom-aggregation-web-part/
• http://blog.mastykarz.nl/performance-of-content-aggregation-queries-on-multiple-lists/
• http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409 (Стив Пешка работает с белой книгой "Большие списки")

Answer 2

Я не уверен, что это применимо, но на стороне DVWP есть DataSourCemode = "ListOfLists", который возвращается, как вы уже догадались, список списков. Веб -сервисы имеют аналогичную функциональность с СПИСКИС. Анкет Я бы предположил, что, поскольку эти два уровня позволяют вам получить доступ к информации о списках, не рассматривая их элементы, которые API обеспечит аналогичную функциональность.