Performances des tables SharePoint et des tables de base de données

Question

1. Nous cherchons à stocker des données transactionnelles dans des listes SharePoint. Les listes atteindront facilement plus de 100 000 articles.
2. Comment les performances de la requête seraient-elles comparées aux requêtes sur une table de base de données avec ces colonnes?

Requêtes: Sélection par Id Sélectionnez Où ColumnValue = X Groupe par OrderId Group Par Date

La liste SP sera 6 colonnes en largeur: Id, date, ORDERID (Lookup), Quanity, ItemName, Title

Answer 1

Ne le faites pas. SharePoint ne gère pas correctement les données transactionnelles et fonctionnera mal.

Toutes les capacités que vous pourriez avoir à améliorer les performances au niveau de la base de données (comme l'ajout d'index) peuvent avoir des effets néfastes sur l'installation de SharePoint (bien que des colonnes dans les listes peuvent être « indexés » via SharePoint.

essentiellement SharePoint est conçu dans un but précis (contenu/documents) et d'essayer de le faire faire quelque chose des moyens ordinaires que vous devez combattre la dent d'application et ongles.

Heureusement SharePoint dispose de plusieurs moyens d'intégrer les données transactionnelles en elle.

Tout d'abord (si vous posséder la licence Entreprise la plus chère), vous disposez du catalogue de données métiers qui vous permet d'importer des valeurs de base de données similaires aux éléments de la liste. Si vous ne disposez pas de la licence Enterprise, je peux recommander des contrôles personnalisés/des composants WebPart ou le composant WebPart Data View pour autoriser l'affichage de ces données sur les pages pertinentes de SharePoint. En résumé: En résumé: Vous allez vous préparer à beaucoup de travail inutile en stockant des données transactionnelles dans SharePoint par rapport à d'autres conceptions d'applications hébergeant les données dans des applications de base de données traditionnelles et intégrant à SharePoint.

Answer 2

Les listes SharePoint seront plus lentes.

Plus de surdébit = moins bonne performance.

Answer 3

+1 Non

SharePoint fonctionne principalement en collaboration. Dans votre cas, vous n'aurez qu'à lister les données en lecture seule. Dans votre situation, je recommande de stocker les données dans la base de données SQL, si vous avez besoin de l'afficher dans le portail SharePoint, vous pouvez utiliser BDC ou quelque chose comme partie Web Bamboo Data View. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx

Answer 4

Je suis d'accord avec tous les commentaires ci-dessus. J'ai eu une vaste expérience avec les clients qui voulaient utiliser les listes SharePoint pour des choses qui ne correspondaient pas. Si vous vous inquiétez des performances, les listes SharePoint ne sont pas la solution. Si c'est simplement pour des fins d'archivage et que vous effectuez des recherches peu fréquentes sur les données et que les fonctionnalités de recherche SharePoint vous suffisent, je pourrais le considérer et ne pas le rejeter d'emblée (si vous utilisez MOSS).

Mais je considérerais tous les aspects de ceci avec soin.Il n'est pas trop difficile via les composants WebPart de formulaire de données et le contrôleur secondaire de domaine d'obtenir des données de serveur SQL dans l'environnement SharePoint, mais il est plus difficile d'obtenir des données SharePoint dans d'autres plates-formes ou applications.

Et encore, si la performance est tout à fait une exigence, alors ne le faites pas.

Pour plus d'informations sur les meilleures pratiques d'évolutivité et de performances de SharePoint voir: http://technet.microsoft.com/en-us/library/cc287790.aspx

Answer 5

La règle de base est de limiter les listes de SharePoint 2000 articles pour des raisons de performance.

À 100k, la performance irait "de sucer à souffler". La seule façon que cela pourrait fonctionner est si vous pouviez segmenter l'ensemble de données en plusieurs listes avec moins de 2000 dans chaque.

Answer 6

Je suis également d'accord avec les gars ci-dessus Cependant - un grand nombre des problèmes de performance discutés dans les blogs sont dus au fait que le modèle d'objet SharePoint n'est pas utilisé correctement.

Vous pouvez consulter ma série de blog sur les performances des listes SharePoint sur le blog dynaTrace. Cette série se penche sur le modèle objet SharePoint pour mettre en évidence ce qui se passe réellement entre les serveurs SharePoint et la base de données de contenu

Answer 7

Bien sûr, l'approche proposée n'est pas recommandée.

Mais, étant dans le sujet, here est une bonne doc pour les grandes listes PERF dans WSS

Answer 8

Ayant fait moi-même, je dirais essayer de l'éviter si possible! C'est un champ de mines, surtout après environ 100 000 lignes. Quelque chose qui peut finir par vous mordre aussi, c'est que le robot de recherche peut commencer à temporiser en essayant d'explorer de très grandes listes - vous pouvez augmenter les temps morts, mais c'est le début d'une bataille perdante.