MOSS - Lequel choisiriez-vous - 120+ colonnes supplémentaires, ou une liste chaînée séparée?

Question

J'ai un casse-tête de la conception que je pourrais utiliser des commentaires, donc j'espère que mes collègues experts SharePoint peuvent me aider à cela.

Je gère un ensemble de projets dans une seule liste MOSS (Liste1), où la colonne « Nom du projet » sera traité comme une « clé primaire » (au moins dans mon esprit) pour les listes connexes. Chaque projet aura associé à un ensemble de résultats définis (jusqu'à 37 activités distinctes tout au long de la vie de chaque projet), et chaque livrable suivre une activité importante qui est recommandé de compléter au cours du projet.

Ma pensée initiale était de définir les 37 produits livrables dans une « liste de recherche » séparée (List2), de sorte que chaque produit à livrer avait pas seulement un « Nom Deliverable », mais aussi:

« URL » - un lien vers un wiki non-MOSS séparé, où l'utilisateur peut trouver plus d'informations sur la façon d'accomplir le livrable « Description » - pour donner une explication rapide de ce que les moyens livrables (sans avoir à envoyer l'utilisateur à un serveur hors séparé pour obtenir tous les détails) « Phase du projet » - pour nous aider à filtrer et trier les produits livrables dans l'ordre dans lequel ils doivent être terminés « Rôle » - pour identifier le rôle principal du projet qui est propriétaire de l'achèvement du livrable

Alors je voudrais créer des éléments individuels dans une autre liste (List3), dont chacun était associé à (1) Projet et (2) l'élément « modèle » dans la « Liste des produits livrables de recherche », afin que nous puissions suivre supplémentaires ceux-ci par projet / par délivrables champs:

"Date d'achèvement" - date à laquelle livrable était fini (si jamais) « Comment dispositioned » - une liste déroulante, à partir de laquelle l'utilisateur peut choisir des états tels que « terminé », « reportée », « n / a » ou « toujours en cours » « Notes » - texte libre pour enregistrer des explications plus / justification sur ce qui a été fait et pourquoi

Le seul problème majeur avec cette approche est que le meilleur des conseils pratiques de Microsoft déconseille fortement MOSS Listes avec> 2000 articles dans la liste. Même si nous n'ajouté plus livrables à chaque projet, je crains que nous allons au-delà de 54 projets escaladons (qui combien je suis « allowed » = 2000/37) à très court terme. Création d'instances multiples de List3 est théoriquement possible, mais me semble un cauchemar pour automatiser (comme mon ensemble de projets suivis augmente).

La première alternative que je peux penser est de prédéfinir 37 colonnes supplémentaires dans la liste des projets, ainsi que les (37 x 3) colonnes nécessaires pour permettre à la « date », « disposition » et les champs « notes » que les utilisateurs devront suivre pour chaque livrable. En plus d'avoir à gérer une configuration / conception fragile de chacun des SPD Formulaires et partie Web Pages que je voudrais utiliser pour « enjoliver » l'interface utilisateur pour toute cette gestion de la saisie des données et des données.

Une autre personne autre m'a suggéré est de créer des sous-sites pour chaque projet, et la liste des produits livrables du projet en une seule liste dans le sous-site du projet. Semble poids lourd terriblement pour moi, et je considère que cela ne mon dernier recours.

Comment un de vous retirer ceci dans MOSS (sans compter sur une base de données en dehors, ou tout autre code qui devrait être installé sur le serveur)? Est-il un truc pour faire ce travail, qui est pas évident de la fonctionnalité habituelle MOSS Liste? Y at-il une fonction cachée de MOSS j'utiliser? Un aspect soigné de SharePoint Designer Je n'ai pas encore découvert? I Vous à croire que beaucoup d'autres ont fait face à cette même limitation, et ont compris d'une certaine façon pour le faire fonctionner. Je vous en serais reconnaissant des idées que vous pouvez suggérer des gens - merci à l'avance

Answer 1

Dans mon expérience va> 2000 articles par conteneur (liste, dossier, élément indexé) n'est pas la fin du monde. Pire encore, cependant, est que si vous commencez à utiliser plusieurs listes qui sont liés les uns aux autres (généralement par) lookups. Il devient alors une grande douleur lorsque vous souhaitez filtrer un enfant basé sur une valeur dans son parent qui ne fait pas partie de la recherche. Les rapports sur ces données peut être très lent si vous avez beaucoup de dossiers impliqués dans la jointure.

Mon inclinaison dans le passé a été d'utiliser 3 forme normale, mais cela ne fonctionne pas bien avec des listes SharePoint je donc envisager une structure assez plat. Si vous avez un-à-plusieurs, vous voulez la plupart du temps à utiliser des listes séparées, bien que.

Answer 2

les meilleures pratiques stipule que, pour des raisons de performance de Microsoft, vous ne devriez pas avoir plus de 2000 articles dans une vue ; Vous pouvez très bien avoir des millions d'articles dans une liste, mais vous devez bien définir vos points de vue et l'utilisation de colonnes d'index pour revenir seulement moins de 2000 articles à un moment donné.

Si vos données de liste ne change pas souvent et vous avez beaucoup de mémoire disponible sur le serveur, il est intéressant de regarder PortalSiteMapProvider pour interroger les listes. Plus d'informations sur les différentes méthodes pour interroger des listes et un livre blanc comparative complète peut être trouvée ici .

Vive!

Answer 3

Je recommande l'utilisation sous-site ou collections de sites pour chaque projet. Un site méta du projet peut être défini qui peut RollUp des informations importantes pour les sites du projet. Le site du projet peut alors stocker plus que les produits à livrer, mais peut devenir une priorité pour la collaboration du projet.

conseils de MS est que la performance commence à souffrir si vous utilisez plus de 50.000 collections de sites, donc il y a une certaine souplesse. Les sous-sites peuvent rapidement devenir ingérable pour le stockage de documents car il n'y a pas de bonne façon de se déplacer entre les bases de données d'un sous-site de contenu lorsqu'une base de données de contenu devient trop importante.

Je pense que la collection de sites par l'architecture de projet vous donnera plus flexiblity et abvoid les questions désagréables avec des listes de consultation complexes. Il reposera sur une utilisation assez intelligente des résultats de recherche webpart cependant.

Answer 4

"MOSS Listes avec> 2000 articles dans la liste"

ce n'est pas un problème car il est juste ce que vous montrez dans une vue. Je pense que MOSS n'est pas un Plattform de développement pour ajouter des éléments moe complexes avec d'autres champs. Je dois faire une application normale ASP.NEt SQLserver