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

Question

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

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

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

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

Буду признателен за понимание одного из множества компромиссов или ссылок на ресурсы, которые его обсуждают. Также приветствуются ссылки на общие «корпоративные рекомендации» SharePoint (извините).

Спасибо.

Answer 1

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

Answer 2

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

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

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

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

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

Один массивный сайт (если вы на самом деле имеете в виду сайт здесь, а не семейство сайтов) - это полное нет-нет и плохой дизайн.

Я бы порекомендовал иметь несколько семейств сайтов (что-то вроде общего отдела в вашей компании, таких как отдел кадров, финансы, ИТ), а затем иметь подчиненные. Таким образом, у вас есть одна база данных в 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