Иерархия сайтов SharePoint для внутренней сети компании - несколько сайтов или дочерних сайтов с одним корнем?
Я менеджер по ИТ в производственной компании среднего размера. Мы замерзаем с SharePoint - пока у нас есть один блог в производственном использовании> Это генеральный директор.
У нас есть варианты использования для пары основанных на списках "приложений" с некоторым простым рабочим процессом, который будет реализован одним из наших разработчиков. Мы также хотим дать нашим пользователям (по крайней мере, более технически подкованным) возможность создавать и работать с собственными сайтами департаментов.
Мы обеспокоены, однако, что мы могли бы начать что-то, что могло бы быстро выйти из-под контроля, если бы оно было широко распространено (что было бы хорошо). Поскольку мы на самом деле не понимаем всех компромиссов в архитектуре, мы можем получить огромное количество пользовательских данных в структуре, которая укушает нас в будущем.
Нашим самым большим вопросом является наличие нескольких сайтов для каждого использования по сравнению с одним корневым сайтом, с которого происходит все остальное. Несколько сайтов дадут нам гибкость для внесения изменений или разработки новых функций без создания проблем для всех пользователей. Однако на нескольких сайтах может быть сложнее выполнять резервное копирование, поиск и поддержание профилей / безопасности пользователей. Один массивный сайт, кажется, полностью меняет соотношение цена / качество.
Я был бы признателен за понимание одного из множества компромиссов или ссылок на ресурсы, которые обсуждают это. Также приветствуются ссылки на общие "корпоративные рекомендации" SharePoint (извините).
Благодарю.
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
Это зависит исключительно от ваших потребностей и требований. даже имея в своем распоряжении защищенные веб-приложения для защищенного сайта, я могу предоставить вам одну цитату, воспользовавшись преимуществами резервного копирования. У вас может быть несколько сайтов, на которых данные не изменяются часто, например, политики организации, обработка документов и т. Д. В этом случае регулярное резервное копирование / обход контента при поиске не имеет смысла (хотя вы можете выбрать разностное резервное копирование и инкрементный обход, но все же через неделю или две недели Вы должны сделать полную резервную копию). поэтому я бы посоветовал тщательно проанализировать ваши требования и затем принять решение. Microsoft предоставила хороший список контрольных списков и шаблонов для целей планирования. Несколько ссылок приведены в ответе Мадхура, а остальные вы можете найти в Google.