Elenco SharePoint Procedure ottimali

Question

Sto creando un'applicazione utilizzando SharePoint List per la memorizzazione dei dati. La progettazione dei dati sarebbe simile se si inserisse in un database relazionale, con elementi come molti a molti, chiavi primarie, chiavi esterne.

Mi piacerebbe sapere quali sono le migliori pratiche?

ci sono alcune domande che ho in mente già durante la creazione della lista:

• SharePoint stessa contiene un ID di nascosto. Devo creare il mio ID?
• Qual è il modo migliore per riflettere una chiave esterna? Sta semplicemente creando un campo di ricerca? o pensi che sia meglio solo creare un testo a riga singola e quindi il mio programma collegherà l'ID. Quale usare quale?

Qualsiasi altro suggerimento su questo sarebbe utile. Btw, sto usando SharePoint 2010.

Answer 1

Non lo farei. Se sta per funzionare come un database relazionale, dovresti semplicemente usare un database relazionale. Il problema riscontrato con le chiavi esterne è solo la punta dell'iceberg quando si tratta di utilizzare elenchi come tabelle di database.

Answer 2

Non ci andrei neanche io. Soprattutto non attraverso il BDC. Se devi integrarti con i dati relazionali, puoi farlo direttamente dal codice del flusso di lavoro .NET. È ancora possibile utilizzare SharePoint per avviare i flussi di lavoro e mantenere gli elenchi Attività, ecc.

Se i dati sono relazionali, inserirli in un database relazionale. È buono con quello.

Answer 3

Sono assolutamente d'accordo con gli altri ragazzi. I dati relazionali sono posizionati al meglio in un database progettato appositamente.

Poiché si utilizza SharePoint 2010, si ha un supporto leggermente migliore per la gestione di elenchi di grandi dimensioni mediante la limitazione e campi di ricerca migliorati. Anche il BDC è ora chiamato BCS e supporta l'aggiornamento e la creazione di dati tramite gli elenchi di SharePoint. In teoria questo ti offre altre due opzioni: a. Inserire i dati negli elenchi utilizzando i campi di ricerca e b. Inserire i dati nel database e accedervi tramite BCS.

L'approccio a) è di sicuro durevole solo se gli elenchi non contengono più di un paio di migliaia di voci e potrebbero presentare alcuni problemi a causa della natura dei campi di ricerca. Per l'approccio b) non ho idea di come la BCS si occupa dei dati relazionali. L'ho usato con un semplice dato non correlato da un database e funziona perfettamente. Anche per grandi quantità di dati. Sebbene entrambi gli approcci abbiano il loro svantaggio, hanno comunque il vantaggio di ottenere "l'interfaccia utente e il trimming di sicurezza" gratuitamente ". Penso che dipenda più o meno dal tuo scenario che cosa ha più senso ...

Answer 4

Sono d'accordo che gli elenchi di SharePoint non sostituiscono un database relazionale. Se sei determinato ad avere i dati all'interno di SharePoint, forse pensa di utilizzare i servizi di accesso per creare il tuo diagramma delle relazioni di entità e quindi pubblicare il database in SharePoint utilizzando i servizi di accesso.

Date un'occhiata a questi Canale 9 video per maggiori dettagli circa le possibilità di servizi di accesso

http://channel9.msdn.com/Learn/Courses/Office2010/AccessUnit

Answer 5

In alcuni casi si desidera memorizzare i dati in un database piuttosto che in elenchi di SharePoint, se sei sicuro che questo è ciò che vuoi fare, quindi crei il tuo database e le tue tabelle come faresti normalmente, quindi crei un elenco usando un tipo di contenuto esterno che puoi definire in SharePoint per riflettere i tuoi dati nel tuo database.

Maggiori informazioni su questo argomento qui: http://msdn.microsoft.com/en-us/library/ee557243.aspx