MOSS - Que usted elija - 120+ columnas adicionales, o con una Lista enlazada?

Question

Tengo un diseño de un enigma que podría utilizar algunos comentarios, así que estoy esperando a que mi compañero de SharePoint expertos me puede ayudar a solucionar esto.

Yo soy la gestión de un conjunto de Proyectos en una única MOSS Lista (List1), donde el "Nombre del Proyecto" columna será tratada como una "clave principal" (al menos en mi mente) para las Listas relacionadas.Cada Proyecto tendrá asociada con un conjunto de definidos (hasta 37 actividades separadas a lo largo de cada vida del proyecto), y cada entregable hará un seguimiento de una actividad importante que se recomienda para completar durante el proyecto.

Mi pensamiento inicial fue definir el 37 entregas por separado en una 'Lista de búsqueda' (Lista2), de modo que cada entregable no había sólo un "Entregable Nombre", sino también:

"URL" - la vinculación a una no-MOSS wiki, donde el usuario puede encontrar más información sobre cómo llevar a cabo la entrega de "Descripción" para dar una explicación rápida de lo que el producto medio (sin tener que enviar al usuario a un servidor separado para obtener más detalles) "Fase de proyecto" que nos ayudan a filtrar y ordenar los resultados en el orden en el que se requiere para ser completado "Papel" - para identificar el principal proyecto de la función que posee la finalización de los entregables

A continuación, me gustaría crear elementos individuales en la otra Lista (List3), cada uno de los cuales se asoció con (1) el Proyecto y (2) la 'plantilla' elemento en el 'entregables Lista de búsqueda', de modo que podríamos pista adicional de estos por proyecto o por entrega campos:

"Fecha de terminación" - fecha de entrega fue terminado (si alguna vez) "¿Cómo dispositioned" - una lista desplegable desde la que el usuario puede elegir los estados tales como "completado", "pospuesto", "n/a" o "en proceso" "Notas" - texto de forma libre para grabar más explicaciones/justificación sobre lo que se hizo y por qué

El principal problema con este enfoque es que Microsoft las mejores prácticas de orientación desalienta fuertemente MOSS Listas con más de 2000 artículos en la Lista.Incluso si nunca hemos añadido más entregables para cada Proyecto, me temo que vamos a escala más allá de 54 proyectos (que cómo muchos estoy "permitido" = 2000/37) en muy corto tiempo.La creación de varias instancias de List3 es teóricamente posible, pero me parece una pesadilla para automatizar (como mi sistema de seguimiento de Proyectos crece).

La primera alternativa que se me ocurre es pre-definir 37 columnas adicionales en la lista de Proyectos, además de la (37 x 3) las columnas que se necesitan para habilitar la "fecha", "disposición" y "notas" de los campos que los usuarios necesitan un seguimiento para cada producto.Además de tener que gestionar un frágil de configuración/diseño de cada uno de los SPD de Formularios y Páginas de elementos web que me gustaría utilizar para "bien" de la interfaz de usuario para todos los datos de entrada y gestión de datos.

Otra alternativa alguien sugirió que, para mí, es para crear sub-Sitios para cada Proyecto, y la lista del proyecto entregables en una sola Lista en el proyecto de la sub-Sitio.Me parece muy pesado para mí, y estoy considerando esto sólo como último recurso.

¿Cómo podría alguno de ustedes tirar esto en MOSS (sin depender de una base de datos, o cualquier otro código que deberá ser instalado en el servidor)?¿Hay algún truco para que esto funcione, que no es obvio a partir de la costumbre de MUSGO funcionalidad de la Lista?¿Hay alguna característica oculta de MUSGO que debo usar?Algunas aspecto ordenado de SharePoint Designer no he descubierto todavía?Yo han para creer que muchos otros se han enfrentado a esta misma limitación, y que hemos averiguado algunos forma de hacer el trabajo.Agradecería cualquier idea que la gente puede sugerir - gracias de antemano!

Answer 1

En mi experiencia va> 2000 artículos por contenedor (lista, carpeta, elemento indexado) no es el fin del mundo. Lo que es peor, sin embargo, es si usted comienza a usar varias listas que están vinculados entre sí (normalmente a través de las búsquedas). Entonces se convierte en un gran dolor cuando se desea filtrar un hijo basándose en un valor en su madre que no es parte de la búsqueda. Al informar sobre estos datos puede ser muy lento si usted tiene una gran cantidad de registros implicados en la unión.

Mi inclinación en el pasado ha sido la utilización de 3era forma normal, pero eso no funciona bien con SharePoint a las listas de modo que yo consideraría una estructura bastante plana. Si tiene uno-a-muchos relaciones podrás mayoría desea utilizar listas separadas, sin embargo.

Answer 2

Microsoft las mejores prácticas de los estados que, por razones de rendimiento, no debe tener más de 2000 artículos en un ver;Puedes perfectamente tener millones de elementos en una lista, pero usted debe definir cuidadosamente sus puntos de vista y el uso de columnas de índice para devolver sólo menos de 2000 artículos a la vez.

Si la lista de datos que no cambian a menudo, y usted tiene una gran cantidad de memoria disponible en el servidor, es que vale la pena mirar PortalSiteMapProvider para la consulta de las listas.Más información sobre los diversos métodos de consulta de las listas y una completa comparativa documento puede ser encontrado aquí.

Saludos!

Answer 3

Yo recomendaría el uso de subsitios o colecciones de sitios para cada proyecto. Un sitio del proyecto meta se puede definir que puede rollup información importante para los sitios del proyecto. El sitio del proyecto a continuación, puede almacenar más que los entregables, pero puede convertirse en un foco para la colaboración en el proyecto.

consejos MS es que el rendimiento comienza a sufrir si se utiliza más de 50.000 colecciones de sitios, por lo que hay cierta flexibilidad allí. Subsitios rápidamente puede llegar a ser difícil de manejar cuando se almacena muchos documentos ya que no hay buena manera de mover un subsitio entre bases de datos de contenido cuando una base de datos de contenido es demasiado grande.

Creo que la colección de sitios por la arquitectura del proyecto le dará mayor FLEXIBILIDAD y abvoid los problemas desagradables con listas de búsqueda complejas. Se apoyará en un cierto uso bastante inteligente de la parte web de resultados de búsqueda sin embargo.

Answer 4

"MOSS listas con> 2000 elementos de la lista"

esto no es un problema, ya que es justo lo que usted muestra en una vista. Creo que Moss no es una Plataforma de desarrollo para agregar Moe artículos complejos con más campos. Que debería hacer una aplicación normal SQLserver ASP.NEt