hiérarchie de sites SharePoint pour l'intranet de l'entreprise - plusieurs sites ou sous-sites avec une racine?

Question

Je suis le responsable informatique chez une entreprise de fabrication de taille moyenne. Nous obtenons nos pieds humides avec SharePoint - jusqu'à présent nous avons un blog dans l'utilisation de la production> Il

est le chef de la direction.

Nous avons des cas d'utilisation pour deux à base de liste « applications » avec un certain flux de travail simple qui sera mis en œuvre par l'un de nos développeurs. Nous voulons aussi donner à nos utilisateurs (au moins les plus technophiles) la possibilité de créer et de travailler avec leurs propres sites ministériels.

Pour nous, cependant, que nous pourrions commencer quelque chose qui pourrait rapidement devenir hors de contrôle si elle est largement adoptée (ce qui serait une bonne chose). Étant donné que nous ne comprenons pas vraiment tous les compromis architecturaux, on pourrait se retrouver avec des quantités massives de données utilisateur dans une structure qui nous mord la route.

Notre plus grande question est de savoir si d'avoir plusieurs sites pour chaque utilisation par rapport à un seul site racine à partir de laquelle tout le reste descend. Plusieurs sites pourraient nous donner la flexibilité de faire des changements ou de développer de nouvelles fonctionnalités sans créer des problèmes pour tous les utilisateurs. Cependant, plusieurs sites pourraient être plus difficiles à sauvegarder, rechercher et maintenir des profils d'utilisateur / sécurité. Un énorme site unique semble inverser les coûts / avantages.

Je vous en serais reconnaissant toute idée d'une contre de nombreux arbitrages, ou des liens vers des ressources qui le signalent. Liens vers SharePoint général « entreprise les meilleures pratiques » (désolé) seraient également appréciées.

Merci.

Answer 1

  

Cependant, plusieurs sites pourrait être plus difficile   pour sauvegarder, rechercher et maintenir l'utilisateur   profils / sécurité. Un seul massif   site semble inverser la   coûts / avantages.

Je considérerait cela comme incorrect. D'abord, nous devons préciser quand nous disons plusieurs sites, pouvons-nous dire plusieurs collections de sites ou plusieurs sites -. Ce sont deux choses totalement différentes

Maintenant, même si elles sont plusieurs collections de sites différents, dans la base de données SQL, ils ne sont qu'une base de données, car la base de données est créée en tant que niveau de l'application Web et non au niveau du site.

C'était sur la sauvegarde.

Venir à la recherche et les profils utilisateur, encore une fois votre hypothèse est fausse. Recherche et profils d'utilisateurs sont partagés et ils travaillent sont les services bien tant qu'ils résident en simple fournisseur de services partagés. Les deux sont des services de niveau agricole.

Un site unique est massif (si votre site signifie vraiment pas ici de collection de sites) est un non-non complet et une mauvaise conception.

Je recommande d'avoir plusieurs collections de sites (quelque chose comme département général dans votre entreprise comme RH, Finance, IT) et ensuite subistes en dessous. De cette façon, vous avez une base de données dans SQL pour gérer et vous pouvez toujours l'échelle en ajoutant la base de données de contenu à une application Web existante.

Encore une fois ici, je suppose que vous créez votre topologie au niveau de l'entreprise. Si cela est à un niveau plus bas, il doit être raffiné.

Lire des articles sur la taxonomie et l'architecture du site sur Technet avant d'aller de l'avant avec une.

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

Il dépend uniquement de vos besoins et exigences. même avoir une application web pour déférent site déférent je peux vous fournir une citation prenant sauvegarde comme avantage. Vous pourriez avoir quelques sites où les données ne change fréquemment comme les politiques d'organisation, documents de processus, etc., dans ce cas prendre des sauvegardes régulières / Analyse de la recherche n'a pas de sens (même si vous pouvez opter pour la sauvegarde différentielle et analyse incrémentielle, mais encore dans une semaine ou tous les quinze jours vous devez prendre sauvegarde complète). donc je vous suggère d'analyser soigneusement vos besoins et prendre une décision. Microsoft a fourni une bonne liste de check-list et des modèles à des fins de planification. quelques-uns des liens sont fournis dans la réponse de Madhur et de repos, vous pouvez google sur.