SharePoint Lists vs Database Tables performance

Question

1. Estamos buscando almacenar datos transaccionales en listas de SharePoint. Las listas crecerán fácilmente a más de 100,000 elementos.
2. ¿Cómo se compararía el rendimiento de la consulta con las consultas en una tabla de base de datos con estas columnas?

Consultas: Selección por Id Select Dónde ColumnValue = X Grupo Por OrderId Grupo Por Fecha

La Lista de SP será de 6 columnas de ancho: Id, fecha, OrderId (Lookup), cantidad, Nombre del elemento, Título

Answer 1

No lo hagas. SharePoint no es bueno en el manejo de datos transaccionales y tendrá un mal rendimiento.

Cualquier habilidad que pueda tener para mejorar el rendimiento a nivel de base de datos (como los índices de adición) puede tener efectos perjudiciales sobre la instalación de SharePoint (aunque columnas en las listas pueden ser "indexados" a través de SharePoint.

Esencialmente SharePoint está diseñado para un propósito específico (contenido/documentos) y tratando de conseguir que haga algo fuera de lo común significa que tiene que luchar el diente aplicación y las uñas.

Afortunadamente SharePoint tiene varios medios de integración de datos transaccionales en ella.

En primer lugar (si tiene la licencia Enterprise más cara) tiene el Catálogo de datos profesionales que le permite importar valores de base de datos que aparecerán de forma similar a los elementos de la lista.

Si no tiene la licencia Enterprise, puedo recomendar controles/webparts personalizados o el elemento web Vista de datos para permitir que esos datos se "muestren" en las páginas relevantes dentro de SharePoint.

En resumen: Se preparará para una gran cantidad de trabajo incomparable almacenando datos transaccionales dentro de SharePoint en comparación con otros diseños de aplicaciones que alojan los datos en aplicaciones de bases de datos tradicionales y se integran a SharePoint.

Answer 2

Las listas de SharePoint serán más lentas.

Más gastos indirectos = peor rendimiento.

Answer 3

+1 No

La función principal de SharePoint es la colaboración. En su caso, solo listará los datos como de solo lectura. En su situación, recomendaría almacenar los datos en SQL DB, si necesita mostrarlos en el portal de SharePoint, puede usar BDC o algo así como el elemento web Bamboo Data View. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx

Answer 4

Estoy de acuerdo con todos los comentarios anteriores. He tenido una amplia experiencia con clientes que querían usar listas de SharePoint para cosas que no encajaban. Si le preocupa el rendimiento en absoluto, entonces las listas de SharePoint no son el camino a seguir. Si solo es para fines de archivo y realiza búsquedas infrecuentes en contra de los datos y las características de búsqueda de SharePoint son suficientes para usted, podría considerarlo y no descartarlo de forma inmediata (si está utilizando MOSS).

Pero consideraría todos los aspectos de esto con cuidado.No es demasiado difícil a través de los elementos web de formularios de datos y el BDC para obtener datos del servidor SQL en el entorno de SharePoint, pero es más difícil obtener datos de SharePoint en otras plataformas o aplicaciones.

Y una vez más, si el rendimiento es en absoluto un requisito, entonces no lo hagas.

Para obtener más información de SharePoint mejores prácticas de rendimiento y escalabilidad ver: http://technet.microsoft.com/en-us/library/cc287790.aspx

Answer 5

La regla de oro es para limitar las listas de SharePoint a 2000 artículos por razones de rendimiento.

En 100k, el rendimiento sería "de succión a golpe".

La única forma en que esto podría funcionar es si puede segmentar el conjunto de datos en múltiples listas con menos de 2000 en cada una.

Answer 6

También estoy de acuerdo con los muchachos por encima de Sin embargo, muchos de los problemas de rendimiento discutidos en los blogs se deben al hecho de que el Modelo de objetos de SharePoint no se usa correctamente.

Puede consultar la serie de mi blog sobre el rendimiento de la lista de SharePoint en dynaTrace Blog. Esta serie examina el Modelo de objetos de SharePoint para resaltar lo que realmente está sucediendo entre los servidores de SharePoint y la base de datos de contenido

Answer 7

Por supuesto, no se recomienda el enfoque propuesto.

Pero, al estar en el tema, here es un buen documento para grandes listas Perf en WSS

Answer 8

Una vez hecho esto por mí mismo, yo diría que tratar de evitar, si es posible! Es un campo de minas, especialmente después de aproximadamente 100,000 filas.

Algo que puede llegar a morder usted, así, es que el rastreador de búsqueda puede comenzar el tiempo de espera tratando de arrastrarse realmente grandes listas - puede aumentar los tiempos de espera, pero es el comienzo de una batalla perdida.