Иерархия сайта SharePoint для интрасети компании - несколько сайтов или подсадочных сами с одним корнем?

Question

Я менеджер ИТ в производственной компании среднего размера. Мы промокаем ноги с SharePoint - до сих пор у нас есть один блог в использовании производства> Это генеральный директор.

У нас есть варианты использования для нескольких «приложений» на основе списков с некоторым простым рабочим процессом, который будет реализован одним из наших разработчиков. Мы также хотим дать нашим пользователям (по крайней мере, более технологичным) возможность создавать и работать со своими собственными участками.

Мы обеспокоены, однако, что мы могли бы начать что -то, что могло бы быстро выйти из -под контроля, если это широко принято (что было бы хорошо). Поскольку мы не совсем понимаем все архитектурные компромиссы, мы могли бы получить огромные объемы пользовательских данных в структуре, которая кусает нас в будущем.

Наш самый большой вопрос заключается в том, иметь ли несколько сайтов для каждого использования против одного корневого сайта, с которого все остальное спускается. Несколько сайтов дадут нам гибкость для внесения изменений или разработки новых функций без создания проблем для всех пользователей. Тем не менее, несколько сайтов могут быть труднее для резервного копирования, поиска и поддержания профилей/безопасности пользователей. Один массивный сайт, кажется, обращает вспять стоимость/выгоды.

Я бы признателен за какое-либо понимание того, что один против многих компромиссов или ссылки на ресурсы, которые обсуждают это. Ссылки на общую SharePoint "Best Practices" Enterprise "(извините) также будут оценены.

Спасибо.

Answer 1

Тем не менее, несколько сайтов могут быть труднее для резервного копирования, поиска и поддержания профилей/безопасности пользователей. Один массивный сайт, кажется, обращает вспять стоимость/выгоды.

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

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

Это касалось резервной копии.

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

Единственный массовый сайт (если вы действительно имеете в виду сайт здесь, а не коллекция сайтов)-полный нет-нет и плохой дизайн.

Я бы порекомендовал иметь несколько коллекций сайтов (что -то вроде общего департамента в вашей компании, таких как HR, Finance, IT), а затем у вас под ним. Таким образом, у вас есть одна база данных в SQL для управления, и вы все равно можете масштабироваться, добавив базу данных контента в существующее веб -приложение.

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

Прочитайте некоторые статьи о таксономии и архитектуре сайта на Technet, прежде чем идти вперед с кем -либо.

Planning worksheets for SharePoint Server 2010
http://technet.microsoft.com/en-us/library/cc262451.aspx

Plan sites and site collections
http://technet.microsoft.com/en-us/library/cc263267.aspx

Sites and site collections overview
http://technet.microsoft.com/en-us/library/cc262410.aspx

Plan site navigation
http://technet.microsoft.com/en-us/library/cc262951.aspx

Answer 2

Это зависит исключительно от ваших потребностей и требований. Даже имея отсроченные веб -приложения для Deferent Site, я могу предоставить вам одну цитату, чтобы получить резервное копирование в качестве преимущества. У вас может быть мало сайтов, где данные не часто меняются, такие как организационные политики, обработки документов и т. Д. В этом случае, когда регулярное резервное копирование/ползание поиска не имеет смысла (хотя вы можете выбрать дифференциальное резервное копирование и постепенное ползание, но все же через неделю или две недели Вы должны сделать полную резервную копию). Поэтому я бы предложил тщательно проанализировать ваши требования, а затем принять решение. Microsoft предоставила хороший список контрольных списков и шаблонов для целей планирования. Немногие ссылки предоставляются в ответе Мадхура и отдыхе, на котором вы можете Google.