МОСС – Что бы вы выбрали – более 120 дополнительных столбцов или отдельный связанный список?

Question

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

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

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

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

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

"Дата завершения" - дата, когда поставка была завершена (если вообще) "How disposed" - выпадающий список, из которого пользователь может выбрать состояния, такие как "completed", "отложено", "n/a" или "все еще в процессе" "Заметки" - текст свободной формы для записи дополнительных объяснений / обоснований того, что было сделано и почему

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

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

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

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

Answer 1

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

Раньше я склонялся к использованию третьей нормальной формы, но она не очень хорошо работает со списками SharePoint, поэтому я бы рассмотрел довольно плоскую структуру.Однако если у вас есть отношения «один ко многим», вам, скорее всего, захочется использовать отдельные списки.

Answer 2

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

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

Ваше здоровье!

Answer 3

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

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

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

Answer 4

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

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