MOSS - Welche würden Sie wählen - 120+ zusätzliche Spalten oder eine separate verknüpfte Liste?

Question

Ich habe ein Design Rätsel, das ich auf ein Feedback nutzen könnten, so hoffe ich, meine Kolleginnen und Sharepoint-Experten kann mir dabei helfen zu trainieren.

ich eine Reihe von Projekten leite in einer einzigen MOSS List (List1), wo die „Projektname“ Spalte wird als ‚Primärschlüssel‘ behandelt wird (zumindest in meinem Kopf) für verwandte Listen. Jedes Projekt wird mit ihm eine Reihe von definierten Leistungen verknüpft ist (bis zu 37 separaten Aktivitäten während jeder Laufzeit des Projektes) und jedes lieferbare wird eine signifikante Aktivität verfolgt, wird empfohlen, während das Projekt abzuschließen.

Meine erste Überlegung war die 37 zu erbringenden Leistungen in einer separaten ‚Lookup-Liste‘ (List2) zu definieren, so dass jedes lieferbare einen „Delivernamen“ nicht nur hatte aber auch:

„URL“ - Verknüpfung mit einer separaten nicht-MOSS Wiki, in dem der Benutzer mehr Informationen finden, wie die lieferbaren zu erreichen „Beschreibung“ - eine kurze Erklärung, was die lieferbaren Mittel geben (ohne dass der Benutzer sich auf einem separaten Server senden Sie alle Details zu erhalten) „Projektphase“ - um uns zu helfen filtern und die zu erbringenden Leistungen in der Reihenfolge sortieren, in dem sie erforderlich sind abgeschlossen sein „Rolle“ - die primäre Projektrolle zu identifizieren, die Vervollständigung der lieferbaren besitzt

Dann würde ich einzelne Elemente in einer anderen Liste (List3) erstellen, von denen jede mit (1) dem Projekt verbunden war und (2) die ‚Vorlage‘ Artikeln in der ‚Deliverables Lookup-Liste‘, so dass wir zusätzliche verfolgen konnten diese pro-Projekt / pro zustellbare Feldern:

„Fertigstellung“ - Datum, an lieferbaren fertig war (wenn überhaupt) „Wie dispositioned“ - eine Dropdown-Liste, aus denen der Benutzer Zustände wie „vollendet“ wählen, „verschoben“, „n / a“ oder „noch in Bearbeitung“ „Notes“ - Freiformtext, um weitere Erklärungen / Begründung bespielen, was getan wurde und warum

ein großes Problem bei diesem Ansatz ist, dass Best Practices Führung von Microsoft stark schreckt MOSS Listen mit> 2000 Artikeln in der Liste. Auch wenn wir nie mehr zu erbringenden Leistungen zu jedem Projekt hinzugefügt, ich habe Angst, dass wir über 54 Projekte skaliert werden (die, wie viele ich „erlaubt“ = 2000/37 bin) in sehr kurzer Zeit. mehrere Instanzen von List3 zu schaffen, ist theoretisch möglich, aber scheint mir ein Alptraum zu automatisieren (wie mein Satz verfolgt Projekte wächst).

Die erste Alternative, die ich denken kann, ist vordefinieren 37 weitere Spalten in der Projektliste, sowie die (37 x 3) Spalten notwendig, um das „Datum“, „Disposition“ und „Notizen“ Felder, die die Benutzer zu ermöglichen, müssen für jede Leistungskomponente verfolgen. Plus ein sprödes Konfiguration / Design jedes der SPD Formulare & Webpartseiten verwalten zu müssen, dass ich möchte verwenden „ziemlich hoch“, um die Benutzeroberfläche für alle diese Dateneingabe und Datenmanagement.

Eine weitere Alternative jemand mir vorgeschlagen ist Unter Seiten für jedes Projekt zu erstellen, und die Liste der zu erbringenden Leistungen des Projekts in einer einzigen Liste in der Unter-Site des Projekts. Schwergewicht scheint mir schrecklich, und ich überlege, dies nur als mein letztes Mittel.

Wie würde jemand von euch diese ziehen in MOSS (ohne sich auf eine externe Datenbank oder einer beliebigen Code, der auf dem Server installiert werden müssten) aus? Gibt es einen Trick, um diese Arbeit zu machen, die nicht offensichtlich von der üblichen MOSS Liste Funktionalität ist? Gibt es eine versteckte Funktion von MOSS sollte ich verwenden? Einige ordentlich Aspekt von Sharepoint Designer Ich habe noch nicht entdeckt? I Haben glauben, dass viele andere diese gleiche Einschränkung konfrontiert und herausgefunden habe, einig Weg, es zu arbeiten. Ich würde schätzen, irgendwelche Ideen, die Sie Leute vorschlagen können - Vielen Dank im Voraus

Answer 1

Nach meiner Erfahrung gehen> 2000 Artikel pro Container (Liste, Ordner, indiziert Element) ist nicht das Ende der Welt. Was jedoch noch schlimmer ist, ist, wenn Sie mehrere Listen zu verwenden beginnen, die (in der Regel durch Lookups) miteinander verbunden sind. Dann wird es ein großer Schmerz, wenn Sie ein Kind filtern mögen basierend auf einem Wert in seinem übergeordneten, die nicht Teil der Lookup ist. dieser Daten Berichterstattung kann sehr langsam sein, wenn Sie viele Datensätze in der Verknüpfung beteiligt haben.

Meine Neigung in der Vergangenheit war die 3. Normalform zu verwenden, aber das mit Sharepoint auch nicht funktioniert Listen so würde ich eine ziemlich flache Struktur betrachten. Wenn Sie eine Eins-zu-viele-Beziehungen haben werden Sie meistens wollen separate Listen verwenden, though.

Answer 2

Microsoft Best Practices stellt fest, dass aus Leistungsgründen sollten Sie nicht mehr als 2000 Einzelteile haben in einer Ansicht ; Sie können sehr gut Millionen von Elementen in einer Liste, aber Sie sollten Ihre Ansichten und die Verwendung von Indexspalten sorgfältig definieren nur zurück weniger als 2000 Stück auf einmal.

Wenn Sie Ihre Listendaten nicht oft ändern, und Sie haben viel Speicher auf dem Server zur Verfügung, es lohnt sich auf PortalSiteMapProvider suchen die Listen für die Abfrage. Weitere Informationen über die verschiedenen Methoden Listen abzufragen und ein vollständiger Vergleich White Paper können hier .

Cheers!

Answer 3

Ich würde mit untergeordneten Websites oder Websitesammlungen für jedes Projekt empfehlen. Eine Meta-Projekt-Website kann definiert werden, welche wichtige Informationen für die Projektstandorte Rollup kann. Die Website-Projekt kann dann mehr speichern als nur die Leistungen, sondern ein Schwerpunkt für die Projektzusammenarbeit werden kann.

MS Rat ist, dass die Leistung zu leiden beginnt, wenn Sie mehr als 50.000 Websitesammlungen verwenden, so gibt es eine gewisse Flexibilität. Unterseiten können schnell unhandlich werden, wenn viele Dokumente zu speichern, da es keine gute Möglichkeit ist es, eine Subsite zwischen Inhaltsdatenbanken zu bewegen, wenn eine Inhaltsdatenbank zu groß wird.

Ich denke, die Websitesammlung pro Projektarchitektur wird Ihnen mehr Flexibilität geben und abvoid die fiesen Probleme mit komplexen Lookup-Listen. Es wird jedoch auf einige ziemlich clevere Nutzung der Suchergebnisse webpart verlassen.

Answer 4

"MOSS Listen mit> 2000 Elementen in der Liste"

Das ist kein Problem, da es genau das, was Sie in einer Ansicht anzeigen. Ich denke, MOSS keine Entwicklungsplattform ist komplexer Produkte mit mehr Felder hinzufügen moe. Ich sollte eine normale SQLserver ASP.NEt Anwendung tun