Startseite > SharePoint Server > Speicherung von strukturierten Daten in SharePoint

Speicherung von strukturierten Daten in SharePoint

Die Herausforderung in vielen SharePoint Projekten ist die Speicherung von strukturierten Daten und deren Nutzung durch den Endanwender. Gerade bei größeren Datenmodellen kommt einem Informatiker sofort der Gedanke einer relationalen Datenbank. Auf der anderen Seite bietet SharePoint auch eine Möglichkeit, die strukturierten Daten in Custom Lists (also eigenen definierten Listen) abzulegen. Nun muss also eine Entscheidung her: Datenbank oder SharePoint Listen.

Ich habe mal ein wenig gegoogelt und verschiedene Quellen gefunden für die Thematik. Leider wird sie kaum umfassend behandelt. Grundsätzlich macht es Sinn, ein ERM-Modell vor der Entscheidung zu erstellen, um die Anzahl der Entitäten und Relationen zu erkennen. Weiterhin ist es wichtig, die Mengengerüste für die Daten zu kennen. Erst dann kann man in die Variantenentscheidung gehen.

Variante 1 : Aufbau eines Datenbank-Schema und Abspeichern in relationaler Datenbank

Diese Variante wird empfohlen wenn:
– m:n Relationen im Datenmodell verwendet werden
– Wenn mehr als zwei Entitäten über Relationen miteinander verbunden sind. (z.B. Customer > Invoice > Invoice Product).

Vorteile:

  • Nutzungen von Datenbanktransaktionen bei häufigen gleichzeitigen Schreib- und Lesevorgängen
  • Lesen und Schreiben von Daten ist performant
  • Reports basierend auf den Daten einfacher erstellbar

Nachteile:

  • Selbst programmierte WebParts oder 3rd Party Web Parts für End-User notwendig
  • Rechtemodell muss selbst programmiert werden

Variante 2: Nachbildung des Datenbank-Schema durch selbst definierte SharePoint Listen

Die Daten der Listen liegen letztendlich auf in einer relationalen Datenbank (SQL-Server), aber trotzdem darf man das nicht gleichsetzen mit Variante 1.

Vorteile:

Nutzung der out-of-the-box SharePoint Features:

  • Eingebautes Rechtemodell
  • Fertige Frontends (WebParts) für Endanwender
  • Editierbarkeit in Datenblattansicht oder in Excel direkt
  • Nutzung von Workflows an Listen
  • Suche indiziert Listen
  • Event Handler können an Listen gebunden werden

Nachteile:

  • SharePoint != DBMS -> keine Datenbanktransaktionen
  • Begrenzte Anzahl von Items in einer List-View (Daumenregel: nicht mehr als 2000 Items pro Anzeige; Performance Probleme beim HTML Rendering in SharePoint)
  • Max. Anzahl der Spalten: 4096

Quellen für diesen Artikel:

http://stackoverflow.com/questions/250992/sharepoint-should-i-use-lists-or-a-database

http://msdn.microsoft.com/en-us/library/dd206910.aspx

http://www.sharepointusecases.com/index.php/2008/11/storing-data-in-sharepoint-lists-vs-sql-database/

http://stackoverflow.com/questions/184653/sharepoint-lists-vs-database-tables-performance#184816

http://www.u2u.info/Blogs/Patrick/Lists/Posts/Post.aspx?ID=1772

http://blogs.msdn.com/joelo/archive/2007/11/08/what-not-to-store-in-sharepoint.aspx

Kategorien:SharePoint Server Schlagwörter:
  1. A. Schiemann
    19. Oktober 2011 um 15:43

    Dieser Artikel wurde auf Basis von SharePoint Version 2007 ausgearbeitet.

    Bezüglich der Speicherung von relationalen Daten in Listen gibt es in SharePoint 2010 folgende Verbesserung:

    – Sicherung der Referenziellen Integrität durch Überwachung/Beschränkung von Löschvorgängen an Datensätzen im relatinalen Datenmodell

  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: