SQL Server Performance

Pro y contra de indice compuesto

Discussion in 'Preguntas sobre SQL Server en Español.' started by fjac_pe, Mar 24, 2010.

  1. fjac_pe New Member

    Buen día, regreso después de mucho tiempo, estoy implementando un CMS para un website que hemos desarrollado y al momento de crear el CMS veo necesidad de hacer tablas dependientes de otra, por decir, un requerimiento de cambio tiene items, los items a su vez tienen elementos relacionados y cada elemento tiene 1 o más secciónes y una sección puede tener subsecciones, y estos últimos también pueden tener varios documentos relacionados.
    En terminos de definición o en cascada tendría varios Ids heredados, quería saber si me conviene utilizar una llave correlativa para que mi PK no pese mucho.
    No puedo pegar la imagen que tenía para que pueda ver el diseño.
    Favor si pueden orientarme en esto porque antes tenía tablas hasta de 3 id que no tenía problema pero ahora según normalización tengo índices compuestos hasta de 5 campos.
    Gracias
    fjac_pe, Mar 24, 2010
    #2

  2. Luis Martin Moderator

    No hay documentación exacta sobre el tema.
    Solamente ciertos criterios aprobados por la mayoría.
    No superar los 6 campos en un índice compuesto es uno de esos criterios, pero, a veces, a los efectos de mejorar la performance resulta necesario crear un índice compuesto de más campos.
    Personalmente creo que es más importante revisar qué campos se incluyen en el índice que la cantidad. Por ejemplo no es lo mismo un índice con un campo int que con un campo char de 200.
    Luis Martin, Mar 25, 2010
    #3

  3. fjac_pe New Member

    Hola Luis Martin, tengo una llave compuesta con 6 campos, no debería tener problema en implementar dicha estructura, y mejor aún que todos los campos son del tipo int.
    Saludos
    fjac_pe, Mar 25, 2010
    #4

  4. Luis Martin Moderator

    A mi criterio ningún problema.
    Luis Martin, Mar 25, 2010
    #5

Share This Page