Списки SharePoint против производительности таблиц базы данных

Списки SharePoint будут медленнее.

Больше накладных расходов = худшая производительность.

Не делай этого. SharePoint плохо справляется с обработкой транзакционных данных и будет плохо работать.

Любые возможности, которые могут вам понадобиться для повышения производительности на уровне базы данных (например, добавление индексов), могут отрицательно повлиять на установку SharePoint (хотя столбцы в списках можно «проиндексировать» через SharePoint.

По сути, SharePoint разработан для определенной цели (контент / документы), и попытки заставить его делать что-то необычное означает, что вам придется бороться с приложением зубами и ногтями.

К счастью, в SharePoint есть несколько способов интеграции в него транзакционных данных.

Во-первых (если у вас более дорогая корпоративная лицензия) у вас есть каталог бизнес-данных, который позволяет вам импортировать значения базы данных, которые будут выглядеть аналогично элементам списка.

Если у вас нет лицензии Enterprise, я могу порекомендовать либо настраиваемые элементы управления / веб-части, либо веб-часть просмотра данных, чтобы эти данные «отображались» на соответствующих страницах в SharePoint.

В итоге: Вы будете настраивать себя на выполнение большого количества необязательной работы по хранению транзакционных данных в SharePoint по сравнению с другими проектами приложений, в которых данные размещаются в традиционных приложениях баз данных и интегрируются с SharePoint.

+1 Нет

Основная функция SharePoint - совместная работа. В вашем случае вы просто укажете данные как доступные только для чтения. В вашей ситуации я бы рекомендовал хранить данные в базе данных SQL, если вам нужно отобразить их на портале SharePoint, вы можете использовать BDC или что-то вроде веб-части Bamboo Data View. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx

Я согласен со всеми приведенными выше комментариями. У меня был большой опыт работы с клиентами, которые хотели использовать списки SharePoint там, где они не подходили. Если вас вообще беспокоит производительность, списки SharePoint вам не подходят. Если это просто для архивных целей, и вы выполняете нечастый поиск по данным и вам достаточно функций поиска SharePoint, я мог бы рассмотреть это и не отказываться от этого сразу (если вы используете MOSS).

Но я бы внимательно рассмотрел все аспекты этого. Получить данные сервера SQL в среду SharePoint с помощью веб-частей формы данных и BDC несложно, но получить данные SharePoint в другие платформы или приложения труднее.

И снова, если производительность вообще является требованием, не делайте этого.

Дополнительные сведения о передовых методах масштабирования и производительности SharePoint см. В следующих разделах: http://technet.microsoft.com/en-us/library/cc287790.aspx

Практическое правило - ограничить списки SharePoint до 2000 элементов из соображений производительности.

На 100k производительность будет идти «от отстойника до упора».

Единственный способ, которым это могло бы сработать, - это если бы вы могли сегментировать набор данных на несколько списков с менее чем 2000 в каждом.

Я также согласен с парнями выше Однако многие проблемы производительности, обсуждаемые в блогах, связаны с неправильным использованием объектной модели SharePoint.

Вы можете ознакомиться с серией моих блогов о производительности списков SharePoint в блоге dynaTrace. В этой серии статей рассматривается объектная модель SharePoint, чтобы выделить, что на самом деле происходит между серверами SharePoint и базой данных контента.

Конечно, предлагаемый подход не рекомендуется.

Но, будучи в теме, здесь - хороший документ для перфорации больших списков в WSS.

Сделав это сам, я бы посоветовал по возможности избегать этого! Это минное поле, особенно после примерно 100 000 рядов.

Что-то, что может в конечном итоге вас укусить, - это то, что поисковый сканер может начать тайм-аут, пытаясь сканировать действительно большие списки - вы можете увеличить тайм-ауты, но это начало проигрышной битвы.