MOSS - quale scegliereste - 120+ colonne aggiuntive, o una lista collegata separata?

Question

Ho un enigma di design che potrei usare un feedback su, quindi spero i miei compagni di esperti di SharePoint possono aiutarmi a risolvere la cosa.

Io sono la gestione di una serie di progetti in un unico elenco MOSS (Lista1), in cui la colonna "Nome progetto" sarà trattato come un 'chiave primaria' (almeno nella mia mente) per gli elenchi correlati. Ogni progetto avrà associato un set di risultati definiti (fino a 37 attività distinte tutta la vita di ogni progetto), e ogni deliverable traccerà un'attività significativa che si consiglia di completare nel corso del progetto.

Il mio pensiero iniziale era quello di definire i 37 elaborati in un 'elenco di ricerca' separato (Lista2), in modo che ogni risultato finale non ha avuto solo un "Deliverable nome", ma anche:

"URL" - il collegamento a un wiki non MOSS separata, dove l'utente può trovare maggiori informazioni su come realizzare il risultato finale "Descrizione" - per dare una rapida spiegazione di ciò che significa consegnabili (senza dover inviare all'utente fuori ad un server separato per avere tutti i dettagli) "Fase di progetto" - per aiutarci a filtrare e ordinare i risultati finali nell'ordine in cui sono tenuti ad essere completato "Ruolo" - per identificare il ruolo primario del progetto che possiede il completamento del risultato finale

Poi vorrei creare singole voci in un altro elenco (Lista3), ognuno dei quali è stato associato con (1) Progetto e (2) la voce 'template' nella 'deliverable elenco di ricerca', in modo da poter tenere traccia aggiuntiva questi per-progetto di campi / consegnabili per-:

"Data di completamento" - data in cui erogabile era finita (se mai) "Come disporre gli" - un elenco a discesa, da cui l'utente può scegliere membri come "completato", "rinviato", "n / a" o "ancora in corso" "Note" - testo in formato libero di registrare ulteriori spiegazioni / razionale su ciò che è stato fatto e perché

L'unico grosso problema con questo approccio è che guida migliore pratiche di Microsoft sconsiglia fortemente MOSS liste con> 2000 articoli nella lista. Anche se non abbiamo mai aggiunto più deliverable a ciascun progetto, temo che dovremo scalare oltre 54 progetti (che quanti sto "permesso" = 2000/37) in modo molto breve. Creazione di più istanze di Lista3 è teoricamente possibile, ma mi sembra un incubo per automatizzare (come la mia serie di progetti monitorati cresce).

La prima alternativa mi viene in mente è quello di predefinire 37 colonne aggiuntive nella lista progetti, più i (37 x 3) le colonne necessarie per consentire la "data", "disposizione" e "Note" campi che gli utenti sarà necessario tenere traccia di ogni deliverable. Inoltre dover gestire una configurazione / disegno fragile ciascuna delle forme SPD e pagine web part che mi piacerebbe usare per "abbellire" l'interfaccia utente per tutte questa voce e di dati gestione dei dati.

Un altro qualcuno alternativa mi ha suggerito è quello di creare sotto-siti per ogni progetto, ed elencare deliverable del progetto in un unico elenco di sub-sito del progetto. Sembra terribilmente pesi massimi a me, e sto considerando questo solo come la mia ultima risorsa.

Come sarebbe qualcuno di voi tirare fuori questo in MOSS (senza fare affidamento su un database esterno, o qualsiasi codice che avrebbe dovuto essere installato sul server)? C'è qualche trucco per fare questo lavoro, che non è evidente dalla solita funzionalità MOSS List? C'è qualche caratteristica nascosta di MOSS devo usare? Alcuni aspetti ordinata di SharePoint Designer non ho ancora scoperto? I sono di credere che molti altri hanno affrontato questo stesso limite, e ho capito alcuni modo per farlo funzionare. Apprezzerei tutte le idee voi gente può suggerire -! Grazie in anticipo

Answer 1

Nella mia esperienza di andare> 2000 articoli per contenitore (elenco, una cartella, elemento indicizzato) non è la fine del mondo. Quel che è peggio, però, è se si inizia ad utilizzare più elenchi che sono collegati gli uni agli altri (in genere attraverso le ricerche). Allora diventa un grande dolore quando si desidera filtrare un bambino sulla base di un valore nel suo genitore che non fa parte della ricerca. Segnalazione su questi dati può essere molto lento se si hanno un sacco di dischi coinvolti nel join.

La mia inclinazione in passato è stata quella di utilizzare terza forma normale, ma che non funziona per bene con SharePoint elenca quindi vorrei prendere in considerazione una struttura abbastanza piatta. Se si dispone di uno-a-molti la maggior parte ti consiglia di utilizzare gli elenchi separati, però.

Answer 2

best practice di Microsoft afferma che, per motivi di prestazioni, non si dovrebbero avere più di 2000 elementi in una Visualizza ; Si può benissimo avere milioni di voci in un elenco, ma si dovrebbe attentamente definire i vostri punti di vista e l'uso di colonne di indice per restituire solo meno di 2000 articoli in una sola volta.

Se i dati elenco non cambia spesso e hanno un sacco di memoria disponibile sul server, vale la pena di guardare PortalSiteMapProvider per l'interrogazione delle liste. Maggiori informazioni sui vari metodi per interrogare list e un white paper di confronto completo è disponibile qui .

Cheers!

Answer 3

Ti consiglio di utilizzare siti secondari o raccolte siti per ogni progetto. Un sito del progetto meta può essere definito che può rollup importante per i siti del progetto. Il sito del progetto può quindi memorizzare più che i risultati finali, ma può diventare un punto di riferimento per la collaborazione a progetto.

I consigli di MS è che le prestazioni comincia a soffrire se si utilizzano più di 50.000 raccolte siti, per cui v'è una certa flessibilità lì. Sub-siti possono rapidamente diventare ingestibile quando la memorizzazione di molti documenti in quanto non v'è alcun buon modo di muoversi un sito secondario tra i database del contenuto quando un database del contenuto diventa troppo grande.

Credo che la raccolta siti per ogni progetto di architettura vi darà una maggiore flexiblity e abvoid i problemi brutto con elenchi di ricerca complessi. Essa si baserà su un certo uso abbastanza intelligente dei risultati di ricerca webpart tuttavia.

Answer 4

"MOSS liste con> 2000 articoli nella lista"

questo non è un problema in quanto è proprio quello che si mostra in una vista. Credo che MOSS non è un plattform di sviluppo per aggiungere moe oggetti complessi con più campi. Devo fare una normale applicazione SQLserver ASP.NEt