MOSS - Что бы вы выбрали - 120+ дополнительных столбцов или отдельный связанный список? - PullRequest
2 голосов
/ 26 марта 2009

У меня есть загадка дизайна, о которой я мог бы использовать некоторые отзывы, поэтому я надеюсь, что мои коллеги-эксперты по SharePoint помогут мне решить эту проблему.

Я управляю набором проектов в одном списке MOSS (List1), где столбец «Имя проекта» будет обрабатываться как «первичный ключ» (по крайней мере, на мой взгляд) для связанных списков. Каждый проект будет связан с определенным набором результатов (до 37 отдельных действий в течение жизни каждого проекта), и каждый результат будет отслеживать одно значительное действие, которое рекомендуется выполнять в течение проекта.

Сначала я хотел определить 37 результатов в отдельном «Списке поиска» (List2), чтобы каждый результат имел не только «Имя доставки», но также:

«URL» - ссылка на отдельную не-MOSS wiki, где пользователь может найти больше информации о том, как выполнить результат «Описание» - чтобы дать быстрое объяснение того, что означает результат (без необходимости отправлять пользователя на отдельный сервер, чтобы получить какие-либо подробности) «Фаза проекта» - чтобы помочь нам отфильтровать и отсортировать результаты в порядке, в котором они должны быть выполнены «Роль» - для определения основной роли проекта, которому принадлежит завершение результата

Затем я бы создал отдельные элементы в другом Списке (List3), каждый из которых был связан с (1) Проектом и (2) элементом 'template' в 'Списке результатов поиска', чтобы мы могли отслеживать дополнительные эти поля для проекта / для поставки:

«Дата завершения» - дата окончания доставки (если когда-либо) «Как расположен» - раскрывающийся список, из которого пользователь может выбрать такие состояния, как «завершено», «отложено», «нет» или «все еще в процессе» «Примечания» - текст в свободной форме для записи дополнительных объяснений / обоснований того, что было сделано и почему

Одной из основных проблем этого подхода является то, что руководство Microsoft по рекомендациям настоятельно не рекомендует спискам MOSS содержать более 2000 элементов в списке. Даже если мы никогда не добавим больше результатов для каждого проекта, я боюсь, что мы будем масштабировать за пределы 54 проектов (что, как мне представляется, «разрешено» = 2000/37) в очень короткие сроки. Создание нескольких экземпляров List3 теоретически возможно, но автоматизация кажется мне кошмаром (по мере роста моего набора отслеживаемых проектов).

Первая альтернатива, о которой я могу подумать, - это предварительно определить 37 дополнительных столбцов в списке проектов, а также (37 x 3) столбцы, необходимые для включения полей «дата», «расположение» и «примечания», которые пользователи нужно будет отслеживать для каждого результата. Кроме того, необходимо управлять хрупкой конфигурацией / дизайном каждой из форм SPD и страниц веб-части, которые я хотел бы использовать, чтобы «нарядить» пользовательский интерфейс для всего этого ввода данных и управления данными.

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

Как кто-нибудь из вас осуществит это в MOSS (не полагаясь на внешнюю базу данных или какой-либо код, который должен быть установлен на сервере)? Есть ли какая-то хитрость, чтобы сделать эту работу, что не очевидно из обычной функциональности MOSS List? Есть ли какая-то скрытая особенность MOSS, которую я должен использовать? Какой-то изящный аспект SharePoint Designer, который я еще не обнаружил? У меня есть , чтобы поверить, что многие другие столкнулись с таким же ограничением, и нашли некоторый способ заставить его работать. Буду признателен за любые идеи, которые вы, ребята, можете предложить - заранее спасибо!

Ответы [ 4 ]

4 голосов
/ 26 марта 2009

Согласно рекомендациям Microsoft, по соображениям производительности в представлении не должно быть более 2000 элементов; Вы можете прекрасно иметь миллионы элементов в списке, но вы должны тщательно определить свои представления и использовать столбцы индекса, чтобы одновременно возвращать менее 2000 элементов.

Если данные списка не меняются часто, и на сервере имеется много памяти, стоит обратиться к PortalSiteMapProvider для запроса списков. Более подробную информацию о различных методах запроса списков и полный сравнительный технический документ можно найти здесь .

ура!

1 голос
/ 26 марта 2009

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

Совет MS заключается в том, что производительность начинает снижаться, если вы используете более 50 000 семейств сайтов, поэтому здесь есть некоторая гибкость. Суб-сайты могут быстро стать неуправляемыми при хранении многих документов, поскольку нет хорошего способа перемещения дочернего сайта между базами данных контента, когда база данных контента становится слишком большой.

Я думаю, что семейство сайтов для каждой архитектуры проекта даст вам большую гибкость и избавит от неприятных проблем со сложными поисковыми списками. Однако он будет опираться на довольно умное использование веб-части результатов поиска.

1 голос
/ 26 марта 2009

По моему опыту,> 2000 элементов в контейнере (список, папка, индексированный элемент) - это не конец света. Что еще хуже, если вы начинаете использовать несколько списков, которые связаны друг с другом (как правило, с помощью поиска). Тогда это становится большой болью, когда вы хотите отфильтровать дочерний элемент на основе значения в его родительском элементе, которое не является частью поиска. Отчетность по этим данным может быть очень медленной, если в объединении задействовано много записей.

В прошлом я склонялся к использованию 3-й нормальной формы, но это плохо работает со списками SharePoint, поэтому я хотел бы рассмотреть довольно плоскую структуру. Если у вас есть отношения один-ко-многим, вам, скорее всего, понадобится использовать отдельные списки.

0 голосов
/ 04 апреля 2009

"Списки MOSS с> 2000 элементами в списке"

это не проблема, а то, что вы показываете в представлении. Я думаю, что MOSS не является платформой разработки, чтобы добавлять более сложные предметы с большим количеством полей. Я должен сделать обычное приложение SQLserver ASP.NEt

...