Καλησπέρα.

 Έχω λίστα στο Sharepoint η οποία έχει φτάσει στα 3000 rows.  Με το που ξεπέρασε η λίστα τα  2000 rows παρατηρήθηκαν μεγάλες καθυστερίσεις στο άνοιγμα προβολών(view) ,  στο άνοιγμα ενός item της λίστας (επεξεργασία είτε προβολή) ακόμα και στο insert ενός στοιχείου. Με το που έβαλα index στην λίστα στα πεδία που φιλτράρουν της προβολές το πρόβλημα με το άνοιγμα των προβολών λύθηκε όμως παραμένουν οι καθυστερίσεις στο άνοιγμα ενός στοιχείου και στην επεξεργασία του (insert ή update). Υπαρχει λύση σε αυτό το θέμα;; Τα 3000 στοιχεία μου φαίνεται πολύ μικρός αριθμός στοιχείων για να δημιουργούνται τέτοιες σημαντικές καθυστερίσεις από τώρα.

Ευχαριστώ εκ των προτέρων.

Ευα

Το πρόβλημα που αναφέρεις είναι γνωστό και γι αυτό προτείνεται να μην ξεπερνάει ένα folder/library τα 2000 items. Το όριο είναι ψιλο-hard και δεν αλλάζει με κάποιο service pack. Η μόνη εναλλακτική είναι να σπάσεις τη μία σου λίστα/βιβλιοθήκη σε πολλές, π.χ. βάση θεματικής κατηγορίας ή τμήματος. Αν τα items για μία από τις επιμέρους λίστες είναι τόσα ώστε να ξεπερνούν πάλι το όριο θα πρέπει να φτιάξεις δύο λίστες, μία current και μία archive στην οποία θα μεταφέρεις περιοδικά τις παλαιότερες εγγραφές /αρχεία.
Όπως και να έχει θα πρέπει να βεβαιωθείς ότι το Sharepoint σου έχει το Service Pack 2 καθώς βελτιώθηκε λίγο η κατάσταση στον τομέα της ταχύτητας. Μερικές ακόμα βελτιώσεις προστέθηκαν στο August 2009 Cumulative update. Το όριο όμως των 2000 εγγραφών δεν καταργήθηκε.

Θα πρέπει να έχεις υπόψη ότι το Sharepoint δεν είναι ούτε φτιάχτηκε ποτέ ως βάση δεδομένων και οι λίστες δεν φτιάχτηκαν για να χρησιμοποιούνται ως πίνακες. Στο τυπικό σενάριο του document management και collaboration δύσκολα φτάνει κάποιος στις 2000 ανακοινώσεις, τα 2000 meetings ή τα 2000 έγγραφα σε ένα και μόνο φάκελο. Αυτά τουλάχιστον θεωρούσαν όταν φτιάχτηκε το Sharepoint πριν 3 χρόνια. Υπάρχουν μάλιστα περιπτώσεις που το Sharepoint μπορεί να σκάσει αν βρει περισσότερες από 2000 εγγραφές σε ένα φάκελο. Γι αυτό θα πρέπει να έχεις βάλει το τελευταίο service pack για να αποφύγεις τυχόν σκασίματα.

Θα πρότεινα όμως να ξανασκεφτείς για ποιό λόγο αποθηκεύεις τόσα πολλά items στη λίστα. Είναι σπάνιο να αποθηκεύεις τα πάντα σε μία και μόνο λίστα. Αν π.χ. θέλεις να καταχωρήσεις ανακοινώσεις μπορείς να δημιουργήσεις ξεχωριστές βιβλιοθήκες ανά τμήμα, ανά θεματική κατηγορία ή ακόμα και ανά κατηγορία χρηστών. Μπορείς μετά με ένα Content Query Web Part ή με κώδικα να μαζέψεις όλες τις ανακοινώσεις από όλες τις βιβλιοθήκες, subsites κλπ και να τις δείξεις σε ένα κοινό grid.
Επίσης, μήπως θα ήταν καλύτερα να τα αποθηκεύσεις απευθείας σε κάποια βάση? Δεν έχει νόημα να αποθηκεύεις στοιχεία στο Sharepoint αν δεν συμμετέχουν στο Full Text Search ή αν δεν σκοπεύεις να τα δείξεις απευθείας στους χρήστες (πχ. δεν υπάρχει λόγως να αποθηκεύσεις ένα trace log στο Sharepoint).

Η κατάσταση αυτή αλλάζει με το Sharepoint 2010. Στην πραγματικότητα βλέπεις, υπάρχουν λιστο-ειδή πράγματα τα οποία τελικά ο κόσμος θέλει να τα βάλει στο Sharepoint, π.χ. αναφορές κλήσεων σε ένα helpdesk, support center, γραμμή πελατών κλπ. 10 κλήσεις την ημέρα να λαμβάνεις, ξεπέρασες το όριο σε 1 μόλις χρόνο. Σε τέτοιες περιπτώσεις είναι δύσκολο να βρεις ένα λογικό διαχωρισμό για να σπάσεις τη λίστα σε μικρότερες. Έτσι λοιπόν άλλαξε ο τρόπος αποθήκευσης στο Sharepoint για να υποστηρίζει εκατομμύρια items χωρίς πτώση των επιδόσεων.

Οπότε από ότι καταλαβαίνω δεν το γλιτώνω το σπάσιμο σε πολλές λίστες. Αν ειναι έτσι όπως τα λέτε τότε μάλλον ήταν λανθασμένος ο σχεδιασμός μας εξαρχής. θα έπρεπε να χρησιμοποιήσουμε πίνακα, αλλά τώρα είναι αργά. Στην ουσία ειναι μια τελείως custom inhouse εφαρμογή workflow στην οποία τα στοιχεία έγκρισης αποθηκεύονται στη λίστα του Sharepoint. Μάλλον δεν θα μπορούμε να περιμένουμε το Sharepoint 2010 οπότε μάλλον το σπάσιμο της λίστας σε περισσότερες θα γίνει προγραμματιστικά. απλά θέλαμε να αποφύγουμε αυτό γιατί μετά θα γίνει πιο πολύπλοκο το θέμα με τις προβολές (οι οποίες τώρα είναι κοινές για όλους τις χρήστες τις εταιρίας και αναφέρονται μόνο σε μια λίστα).

Ευχαριστώ πολύ για την άμεση απάντηση.