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

Question

Je suis le directeur informatique d'une entreprise manufacturière de taille moyenne. Nous commençons à nous mouiller les pieds avec SharePoint - jusqu'à présent, nous avons un blog en production> C'est le PDG.

Nous avons des cas d'utilisation pour quelques "applications" basées sur des listes avec un workflow simple qui sera implémenté par l'un de nos développeurs. Nous voulons également donner à nos utilisateurs (au moins les plus experts en technologie) la possibilité de créer et de travailler avec leurs propres sites départementaux.

Nous craignons toutefois que nous ne commencions quelque chose qui pourrait rapidement échapper à tout contrôle s'il est largement adopté (ce qui serait une bonne chose). Puisque nous ne comprenons pas vraiment tous les compromis architecturaux, nous pourrions nous 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 s'il faut avoir plusieurs sites pour chaque utilisation par rapport à un seul site racine à partir duquel tout le reste descend. Plusieurs sites nous donneraient la flexibilité d'apporter des modifications ou de développer de nouvelles fonctionnalités sans créer de problèmes pour tous les utilisateurs. Toutefois, plusieurs sites peuvent être plus difficiles à sauvegarder, à rechercher et à gérer les profils/la sécurité des utilisateurs. Un seul site massif semble inverser les coûts/bénéfices.

J'apprécierais tout aperçu sur le un contre de nombreux compromis, ou des liens vers des ressources qui en discutent. Des liens vers les «meilleures pratiques d'entreprise» de SharePoint (désolé) seraient également appréciés.

Merci.

Answer 1

Cependant, plusieurs sites peuvent être plus difficiles pour sauvegarder, rechercher et maintenir l'utilisateur profils/sécurité. Un seul site massif semble inverser le coût/avantages.

Je considère cela comme incorrect. Nous devons d'abord clarifier quand nous disons plusieurs sites, entendons-nous plusieurs collections de sites ou plusieurs sites? Ce sont deux choses totalement différentes.

Maintenant, même s'il s'agit de plusieurs collections de sites différentes, dans la base de données SQL, elles ne constituent qu'une base de données, car la base de données est créée au niveau de l'application Web et non au niveau du site.

En ce qui concerne la sauvegarde.

En cherchant des profils de recherche et d'utilisateur, votre hypothèse est erronée. Les profils de recherche et d'utilisateur sont des SErvices partagés et ils fonctionnent correctement tant qu'ils résident dans un seul fournisseur de services partagés. Les deux sont des services au niveau de la ferme.

Un seul site massif est (si vous voulez vraiment dire ici site non collection de sites) est un non-non complet et un mauvais design.

Je recommanderais d'avoir plusieurs collections de sites (quelque chose comme le département global dans votre entreprise comme HR, Finance, IT) et ensuite avoir des sous-listes en dessous. De cette façon, vous avez une base de données en SQL à gérer et vous pouvez toujours mettre à l'échelle en ajoutant la base de données de contenu à l'application Web existante.

Ici encore, je suppose que vous créez votre topologie au niveau de l'entreprise. Si c'est à un niveau inférieur, il doit être affiné.

Lisez quelques articles sur la taxonomie et l'architecture du site sur Technet avant d'aller de l'avant.

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

Cela dépend uniquement de vos besoins et exigences. même ayant des applications Web déférentes pour un site déférent je peux vous fournir une sauvegarde de citation comme avantage. Vous pouvez avoir peu de sites où les données ne changent pas fréquemment comme les politiques organisationnelles, les documents de processus, etc. Dans ce cas, effectuer des sauvegardes/explorations régulières n'a pas de sens (bien que vous puissiez opter pour une sauvegarde différentielle et une exploration incrémentielle vous devez prendre une sauvegarde complète). par conséquent, je suggère d'analyser soigneusement vos besoins et ensuite prendre une décision. Microsoft a fourni une bonne liste de liste de contrôle et de modèles à des fins de planification. quelques-uns des liens sont fournis dans la réponse de madhur et reste vous pouvez google sur.