große Liste in eine Seite laden - Performance-Problem

Henning Eiben Als Antwort am 27 Mai 2012 13:37

Ich würde eher die Frage stellen: macht es Sinn alle 3000 Element auf einmal zu laden? Wer guckt sich denn die ganzen Elemente wirklich an? Muss man wirklich alle Elemente gleichzeitig sehen? Evtl. ist es für den Anwender besser, wenn er nur einen Ausschnitt der Daten sieht und nicht alles. Vielleicht kann man Daten filtern oder Paging verwenden.

Ich würde zunächst die Frage stelle: was für Daten sind in der Liste und wie wird damit gearbeitet? Was sind die "Business-Anforderungen"?

Ben Als Antwort am 27 Mai 2012 22:16

So eine Menge an Elementen ist schon heftig ^^. Da es ja Telefonnummern sind, würde ich eher auf Outlook-Kontaktverwaltung gehen. Diese kann man ja dann auch mit SharePoint verbinden

Manfred K. Als Antwort am 28 Mai 2012 09:20

Die Liste soll schon im Intranet abgebildet sein!!!

Henning Eiben Als Antwort am 28 Mai 2012 12:32

Ja, das will ich ja auch garnicht verweigern. Aber die Frage ist: was sind da für Daten drin, wofür und vor allem *wie* soll mit den Daten gearbeitet werden? Wie gesagt: ich bezweifel, dass irgendjemand sich alle 3.000 Elemente ansieht.

Manfred K. Als Antwort am 28 Mai 2012 14:54

Die 3.000 Elemente sind für die Suche da. Ich habe ein Suchfeld, der mir die Liste auf der Seite durchscannt (jquery), dafür sollen die durchsuchten Elemente da sein!

René Fritsch Als Antwort am 28 Mai 2012 18:26

Den Zugriff auf eure Kontaktdaten über die SharePoint-Suche zu realisieren, ist ein guter (und vor allem sehr performanter) Ansatz. In welcher Weise du dabei jQuery brauchst, ist mir allerdings nicht klar. Mein Tipp wäre, so vorzugehen:

1) Such-Bereich (Scope) erstellen, der nur die besagte Liste umfasst

2) Die wichtigsten Spalten der Liste in der Zentraladministration als Managed Property anlegen (--> damit sind sie direkt über die Suche ansprech- bzw. abrufbar)

3) Eine Suchergebnis-Seite erstellen und auf dieser eine übersichtliche, tabellarische Darstellung der Ergebnisse platzieren (dafür musst du das XSL des Core Search Results WebParts anpassen)

Auf diese Weise erreichst du eine saubere Telefonbuch-Lösung, in der nicht nur nach Namen sondern z.B. auch nach Teams gesucht werden kann. In der Vermutung, dass deine Anwendern keine vollständige Ansicht  aller 3000 Kontakte in einer flachen Liste brauchen (oder erwarten) gebe ich Henning Recht.

Henning Eiben Als Antwort am 29 Mai 2012 08:56

Das würde ich anders angehen. Entweder mit der Hilfe der SharePoint Suche, so wie es Rene vorgeschlagen hat. Oder wenn du es mehr Web 2.0 mäßig willst mit der Hilfe von JavaScript.

Ich würde die Liste zunächst nicht laden, sondern nur das Suchformular. Nach der Eingabe des Suchbegriffs könntest du dann mit dem JavaScript ObjectModel eine CAML Abfrage auf die Liste machen und nur die Treffer deiner Suche abrufen und dann tabellarisch anzeigen.