Websitespalten / Website-Inhaltstypen / Listen-Instanzen / Listendefinitionen / Listen-Inhaltstypen

Andi Fandrich Als Antwort am 15 Apr. 2014 09:14

Websitespalten hast Du bereits selbst sehr gut beschrieben. Dazu kann noch eine übergeordnete Version kommen wenn ein Inhaltstyp-Hub zur zentralen Bereitstellung von Inhaltstypen und deren Spalten kommt. Das geht dann auch über die Grenzen von Websitesammlungen hinweg. Und wenn man z.B. einzelne Spalten gezielt für die Suche verwenden möchte (Managed Properties), geht das nur mit Websitespalten.

Websiteinhaltstypen fassen dann einfach mehrere Spalten zu einer Informationseinheit zusammen. Sie können ebenfalls wiederverwendet werden und in Verbindung mit dem Inhaltstyp-Hub auch Websitesammlungsübergreifen.

Listen-Inhaltstypen sind quasi die Instanz eines Inhaltstypen bei einer bestimmten Liste. Sie können hier prinzipiell verändert werden, aber man sollte es nicht tun. Sehr interessant dabei ist, daß man auf einer Liste mehrere Inhaltstypen mit verschiedenen Spalten benutzen kann. Wenn man bei einer Bibliothek z.B. Rechnungen und Angebote speichern möchte, kann man die mit unterschiedlichen Vorlagen und unterschiedlichen Spalten versehen, aber trotzdem in einer Bibliothek speichern. Und es können unterschiedliche Workflows darauf ausgeführt werden.

Die Listendefinition ist ein abstrakte Beschreibung einer Liste. Aus dieser Definition können an unterschiedlicher Stelle Instanzen erzeugt werden. Eine Listeninstanz ist dann eine konkrete Anwendung einer Listendefinition. Sie hat eine feste Adresse (URL) unter der sie erreichbar ist und sie dient als Container zur Aufnahme von Daten.

RedArt Als Antwort am 16 Apr. 2014 10:06

Website-Inhaltstypen verstehe ich immernoch nicht so ganz, kann man jetzt wirklich nur WebsiteSpalten innerhalb dieser hinzufügen, sodass dieses Informationstechnisch mehr oder weniger ein Strukt von WebsiteSpalten ist?

Ebenfalls verstehe ich nicht wann und wo ich diese einsetzen sollte. Wann setze ich diese ein?

Weitere Fragen bezüglich der Datenmodellierung:

Erstens

Wenn ich nachher eine Liste aus Kunden, ihren Standorten usw. machen möchte, so gibt es ja mehrere Möglichkeiten dieses zu bewerkstelligen. Ich könnte eine Websitespalte mit Kundenname erstellen oder die vorhandenen Websitespalten nutzen und die Liste Kunden mit einem Contenttype versehen.

Wie soll man hier am besten vorgehen, um möglichst viele Aspekte von Sharepoint nachher nutzen zu können?

Zweitens

Sind Website-Spalten und Listen-ContentTypes bezüglich der Suche gleich gut? Was muss ich bei der Datenmodellierung beachten, damit später möglichst gut gesucht werden kann? Wie konfiguriere ich die Suche später? [Beispiel ich möchte nach Kunden suchen und gebe einen Anfangsbuchstaben ein, werden mir dann alle Kunden dieses Anfangsbuchstabens schon gezeigt, sodass ich auf diese Klicken kann und weitere Details zu ihren Standorten usw. bekommen kann?

Drittens

Wenn ich viele zentrale Listen besitzen möchte, welche einmal in Sharepoint vorkommen sollen, wäre es angebracht diese auf der obersten Ebene der WebsiteSammlung anzulegen und im Browser zu verstecken?

Die User sollten dann über verschiedene Websites mit Webparts und Listenansichten andere Funktionalitäten dieser Listen bereitgestellt bekommen bzw. erst gar kein Webpart / Listenansicht für manche dieser Listen erhalten. Richtiger Ansatz?

Andi Fandrich Als Antwort am 16 Apr. 2014 10:38

[quote user="RedArt"]Inhaltstypen [...] Informationstechnisch mehr oder weniger ein Strukt von WebsiteSpalten [/quote]

So könnte man das sagen.

[quote user="RedArt"]Wann setze ich diese ein?[/quote]

Kann man nicht so generell sagen. Immer dann, wenn es Sinn hat ;-)

Inhaltstypen sind immer dann sinnvoll, wenn man zentral eine wiederverwendbare Struktur vorgeben möchte. Sie dazu auch den Inhaltstyp-Hub, mit dem Inhaltstypen zentral für viele Websitesammlungen bereitgestellt werden können. Wenn Du also möchtest, daß bestimmte Dokumente immer mit einer Spalte "Kostenstelle" versehen sind, dann lege einen Inhaltstyp dafür an und benutze ihn in allen relevanten Bibliotheken. Beachte auch, daß Inhaltstypen voneinander abgeleitet werden. Wenn Du also einen weiteren Dokumenttyp hast, der nicht nur immer eine Kostenstelle, sondern auch eine Kundennummer enthalten soll, kannst Du einen weiteren Inhaltstyp von dem mit der Kostenstelle ableiten und ihm zusätzlich eine Spalte Kundennummer geben. Und wenn Du später feststellst, daß hier eine Spalte fehlt, füge sie hinzu und Du hast die Spalte in allen Bibliotheken, in der der Inhaltstyp verwendet wird. Außerdem kann man Daten später wieder anhand des Inhaltstyps unterscheiden, z.B. in der Suche.

Du siehst also, daß Inhaltstypen durchaus Sinn haben. Verwende lieber zu viele als zu wenige. Es braucht aber auch eine sinnvolle Planung. Das ist nichts, was man mal so nebenbei bereitstellt.

Das mit der Planung gilt auch für Deine restlichen Fragen. Die kann man nicht so nebenbei in einem Forum beantworten, sondern das muß ausführlich diskutiert werden. Hier nur die einfachsten Antworten:

[quote user="RedArt"]Wenn ich nachher eine Liste aus Kunden, ihren Standorten usw. machen möchte[/quote]

Ja genau. Lege eine Liste an und verwende Inhaltstypen. Vielleicht sind auch zwei Listen sinnvoll, eine für die Kunden und eine für die Standorte.

[quote user="RedArt"]Sind Website-Spalten und Listen-ContentTypes bezüglich der Suche gleich gut?[/quote]

Gezielt suchen kann man immer nur nach Websitespalten und Inhaltstypen. Alles was nur direkt auf einer Liste gemacht wird, kann nicht gezielt verwendet werden.

[quote user="RedArt"]Was muss ich bei der Datenmodellierung beachten, damit später möglichst gut gesucht werden kann?[/quote]

Websitespalten verwenden.

[quote user="RedArt"]Wie konfiguriere ich die Suche später?[/quote]

Alleine das ist ein größeres Thema für sich. Da Du hier im 201er-Forum postest, nehme ich an, daß Du SharePoint 2010 hast. Dort geht noch nicht ganz so viel und manches nicht so komfortable. In SharePoint 2013 ist FAST-Search fester Bestandteil und das ist deutlich besser.

[quote user="RedArt"]Wenn ich viele zentrale Listen besitzen möchte, welche einmal in Sharepoint vorkommen sollen, wäre es angebracht diese auf der obersten Ebene der WebsiteSammlung anzulegen [/quote]

Das kann man nicht pauschal beantworten. Was möchtest Du damit genau erreichen? Wenn es Dir um sowas wie zentrale Nachschlageinformationen geht, dann schaue Dir mal Managed Metadata / Termstore genauer an. Das ist deutlich besser dazu geeignet. Ansonsten gehört eine Liste dorthin, wo sie gepflegt wird. Also wenn es um Mitarbeiterinfos geht in die Website der Personalabteilung. Wenn es um Produktinfos geht in die Website vom Marketing (oder der Technik). Anzeigen kann man diese Daten an anderer Stelle wiederum über die Suche.

RedArt Als Antwort am 16 Apr. 2014 11:20

Ich werde Sharepoint 2013 nutzen bzw. nutze es derzeit in einer VM und möchte bereits alle Listen / Websites / ... erstellen um diese später exportieren zu können, sofern die Firma dann den produktiven Sharepoint Server kauft.

In der Firma muss eine Zentrale Datenablage sein, wo alle Kunden gepflegt werden, sowie alle Anlagen die konstruiert wurden und deren Bearbeitungen dazu. Also ziemlich viele Daten, welches Zentral über die komplette Webanwendung erreichbar sein müssen und nicht nur in einer bestimmten Abteilung.

ich möchte dann kapseln, dass zum Beispiel die Stammdatenpflege von der "Buchhaltung" gemacht wird. Weshalb ich dazu hingehen würde eine Webpart-Listenansicht dieser Zentralen Liste innerhalb der Buchhaltungs-Website zu erstellen (bzw. in einer Unterwebsite dieser).

Allerdings müssen ebenfalls auch Servicemanager auf dieser Liste zugreifen können und diese bearbeiten, diese sehen dann jedoch auch alle Anlagen und Bearbeitungen usw. usw. Da allerdings alle Listen durch LookUps miteiander "verknüpft" sind, müssen diese ja mehr oder weniger auf einer Ebene liegen? Bzw. welchen Sinn hat es dann Kundendateneingabe auf eine andere Ebene zu setzen?

Kann man dann überhaupt von Unterwebsite-Listen auf Root-Listen LookUps erstellen?

Nachfrage zu dem übergeordneten Abschnitt

Sofern ich auf root-ebene Listen erstellen, so kann ich doch auch Berechtigungen auf diese Liste vergeben und diese Liste verstecken oder? Oder muss man so derart kapseln mit den Teamwebsiten usw. damit erst ein geeignetes Rechtekonzept entsteht`?

Datenbank-Frage bzgl. blob / Datein

Werden die Datein in Bibliotheken eigentlich in der Datenbank-Sharepoints gespeichert? (kann ich mir irgendwie nicht vorstellen) Oder existiert nur ein verweis auf deren Speicherort den Sharepoint selber verwaltet? Oder wie ist das konstrukt bei Sharepoint?

Andi Fandrich Als Antwort am 16 Apr. 2014 11:58

[quote user="RedArt"]ich möchte dann kapseln, dass zum Beispiel die Stammdatenpflege von der "Buchhaltung" gemacht wird. Weshalb ich dazu hingehen würde eine Webpart-Listenansicht dieser Zentralen Liste innerhalb der Buchhaltungs-Website zu erstellen [/quote]

Ganz anderer Vorschlag: die Anlagen haben bestimmt eine eindeutige Nummer oder sonst ein Ident-Merkmal. Das würde ich im Termstore pflegen als einziges zentrales Element. Dann gibt es ein Liste oder Bibliothek bei der Buchhaltung, die dort "ihre" Daten pflegt und mit dem Termstorefeld verbindet. Ebenso bekommt die Technik eine Liste oder Bibliothek. Und das Marketing und der Vertrieb.

Jetzt hast Du viele separate Datensätze an vielen verschiedenen Stellen, aber mit dem Vorteil, daß jeder an seinem gewohnten Ort arbeiten kann. Und die Daten haben alle ein gemeinsames Merkmal, nämlich die Anlagennummer aus dem Termstore. Über die Suche kann man dann nach einer Anlagennummer suchen und bekommt alle Informationen dazu, egal wo die Information physikalisch liegt. Und man bekommt automatisch nur die Informationen, die man auch sehen darf. Wenn jemand kein Recht auf die Vetriebsdaten hat, dann sieht er sie auch nicht. Und die Ansicht muß dabei überhaupt nicht nach Suchergebnis aussehen - sie läßt sich anpassen.

[quote user="RedArt"]Werden die Datein in Bibliotheken eigentlich in der Datenbank-Sharepoints gespeichert?[/quote]

Ja, Dokumente werden standardmäßig als Blob in der Datenbank abgelegt. Eine Datenbank sollte dabei nicht größer als 100-200 GB werden und man kann pro Websitesammlung eine eigene Datenbank verwenden.

Wenn man das nicht möchte, kann man im SQL Server RBS (Remote Blob Storage) einrichten und damit Dokumente im Dateisystem ablegen. Das ist aber mit erhöhtem Aufwand verbunden (z.B. Backup/Restore) und es hat auch nicht in jedem Szenario Sinn, z.B. wenn eher viele kleinere Dateien verwendet werden.

RedArt Als Antwort am 17 Apr. 2014 09:35

Erste Frage, warum kann man in Sharepoint Designer 2013 nicht den Website-Spaltentyp Verwaltete Metadaten auswählen sondern nur über Website-Einstellungen -> WebsiteSpalten. Oder mache ich da etwas falsch?

Weitere Beschreibungen + Fragen:

Wenn ich nun ein-eindeutigen Werte für Anlagen habe, so müssten diese ja von einem Termstore-Manager eingepflegt werden. Dann kann ich eine WebsiteSpalte von Verwalteten Metadaten machen und diese in der Anlagen-Liste hinzufügen.

Was nun allerdings nicht mehr funktioniert ist ein LookUp auf dieses Feld der Metadaten. Oder geht das doch? In diesem Unternehmen spricht man bisher immer Anlagen über diese Nummern an. Wenn ich nachher eine Liste habe, welche alle Bearbeitungen an Anlagen enthält, empfinde ich eine LookUp-Column auf eben diese Nummer als äußerst wertvoll. Wäre es dann sinnvoll eine weitere Website-Spalte Anlagennummer zu setzen, welche dann gleich der Nummer im Termstore ist?

Wenn ich dies nun weiter denke, dann müsste der Termstore doch nachher auch jeder Standort, jeder Kunde, ... als Verwaltete Metadaten-Spalte existieren, sodass nachher gescheit gesucht werden kann. Vorallem dadurch das diese Daten ja eigentlich dann nur noch in der "Buchhaltung" existieren, da diese Liste ja dann nur noch dort vorhanden ist. Ist das nicht in gewisser Weise ein "OVERKILL", oder Aufwand der geleistet werden sollte?

Konzeptionsfrage:

Nun wären die einzelnen Listen ja auf den jeweiligen Teamwebseiten (Welches Unterseiten der Webanwendung sind? Und dann jeweils viele WebsiteSeiten besitzen können?) Möchte ein Service-Mitarbeiter alle Anlagen mit ihren Bearbeitungen eines gewissen Kunden an einem Standort gezeigt bekommen, konnte ich dieses vorher mit verbundenen Webparts machen. Könnte ich diese Ansicht trotzdem noch realisieren, obwohl die Kunden und Standortliste nun der "Buchhaltung" gehört? Oder würde dann mittels der Suche (die ich wirklich noch überhaupt nicht einschätzen kann) besser funktionieren? Könnte man dann in einem SuchFeld, Suchergebnisfeld soetwas einschränken? Durch einen BearbeitungsContentType, AnlagenContentType...?

LookUps finden immer auf ID statt:

Kunden

Standorte besitzen derzeit LookUp auf einen Kunden

Ansprechpartner besitzen LookUp auf einen Standort

Mutteranlagen besitzen derzeit LookUps auf mehrere "Standorte" (Hersteller, Zwischenkunde, Endkunde..)

Anlagen besitzen derzeit LookUps auf Mutteranlagen, Projektleiter, Kundennummern

Kundennummern besitzen LookUp auf Anlage

Bearbeitungen enthalten LookUp auf Anlage, Mitarbeiter, Auftrag

Aufträge enthalten LookUp auf Mutteranlagen, Ansprechpartner

Programmdatein enthalten LookUp auf Anlagen und Mitarbeiter

....

Das Problem was ich dabei habe ist von einem Entity Relationship Diagramm mehr oder weniger eine sehr sehr sinnvolle Übersetzung zu Sharepoint zu finden. Vorallem dann die Trennungsbereiche zu setzen von den verschiedenen Bereichen (Buchhaltung hat Kunde, Standort, Ansprechpartner ...), Technik hat Mutteranlage, Schaltanlage, Programme, usw.

Welche Technologien brauche für eine sehr geeignete Struktur in Sharepoint?

(Website-Spalten auf WebsiteSammlungs-ebene, Verwaltete Metadaten auf WebsammlungsEbene, Lookups richtige Wahl? [Das macht verknüpfen von Webpart-Listenansichten recht einfach da ID = LookUp einer untergeordneten Listeninstanz usw.] und vorallem wo setze ich diese dann ein? Welche Konsequenz ergibt sich dadurch für den Endanwender...?

Andi Fandrich Als Antwort am 17 Apr. 2014 10:35

Zu Deinen Fragen:

[quote user="RedArt"]warum kann man in Sharepoint Designer 2013 nicht den Website-Spaltentyp Verwaltete Metadaten auswählen [/quote]

Das mußt Du Microsoft fragen. SharePoint Designer ist ohnehin mit Vorsicht zu genießen. Für Workflows gibt es keine Alternative (außer Drittanbieter wie Nintex), aber für das meiste andere muß man ihn nicht benutzen. Das Teil ist sowas von bugverseucht...

[quote user="RedArt"]Was nun allerdings nicht mehr funktioniert ist ein LookUp auf dieses Feld der Metadaten[/quote]

Nein, Lookups auf diese (und andere) Spalten gehen nicht.

[quote user="RedArt"]Wäre es dann sinnvoll eine weitere Website-Spalte Anlagennummer zu setzen, welche dann gleich der Nummer im Termstore ist?[/quote]

Das wäre ein Möglichkeit. Die Spalte kann ja für Benutzer nicht pflegbar sein und wird von einem Workflow befüllt.

[quote user="RedArt"]

Wenn ich dies nun weiter denke, dann müsste der Termstore doch nachher auch jeder Standort, jeder Kunde, ... als Verwaltete Metadaten-Spalte existieren, [...] Ist das nicht in gewisser Weise ein "OVERKILL", oder Aufwand der geleistet werden sollte?[/quote]

Ob es den Aufwand wert ist, hängt natürlich u.a. von der Datenmenge ab. Meistens lohnt es sich aber. Die Initialbefüllung kann man übrigens per CSV-Import machen und muß nicht alles manuell anlegen.

[quote user="RedArt"]Möchte ein Service-Mitarbeiter alle Anlagen mit ihren Bearbeitungen eines gewissen Kunden an einem Standort gezeigt bekommen, konnte ich dieses vorher mit verbundenen Webparts machen. Könnte ich diese Ansicht trotzdem noch realisieren, obwohl die Kunden und Standortliste nun der "Buchhaltung" gehört? Oder würde dann mittels der Suche (die ich wirklich noch überhaupt nicht einschätzen kann) besser funktionieren? Könnte man dann in einem SuchFeld, Suchergebnisfeld soetwas einschränken? Durch einen BearbeitungsContentType, AnlagenContentType...?[/quote]

Ja, sowas kann man sehr gut mit der Suche machen. Google mal nach Search Refiner. Man kann definieren, welche Eigenschaften (Content Type, Anlagennr. usw.) als Refiner verwendet werden sollen. Die erscheinen dann links neben den Suchergebnissen und man kann einfach auf einen Wert klicken und filtert damit die Suchergebnisse. Das geht auch mit mehreren Werten. Ist sehr komfortable und sehr schnell.

[quote user="RedArt"]Das Problem was ich dabei habe ist von einem Entity Relationship Diagramm mehr oder weniger eine sehr sehr sinnvolle Übersetzung zu Sharepoint zu finden[/quote]

Das ist bei jedem Projekt schwierig. Man darf aber nicht von einem vielleicht gewohnten Datenmodell einer relationalen Datenbank einfach auf SharePoint-Listen schließen. Bei einer simplen 1:n-Bezieheung (z.B. Firma-Ansprechpartner) kann man das noch einfach mit zwei Listen machen, aber für größere Geschichten ist oft eine andere Aufteilung und Verteilung an verschiedene Stellen sinnvoller.

An der Stelle kann man auch keine generellen Antworten mehr geben. So ein Projekt muß einigermaßen aufwendig geplant sein und das braucht nun mal viel Erfahrung.