Un índice contiene una copia de sólo unos cuantos campos de una tabla de base de datos. En el índice estos campos se clasifican (en contraposición con los datos de la tabla misma). Esto permite al sistema acceder a los datos del índice más rápidamente. Además, cada entrada de índice "apunta" hacia el registro de datos correspondiente de la tabla.

Cuando existen condiciones especificadas para campos contenidos en un índice durante una orden de búsqueda, el sistema puede procesar parte de esta orden de búsqueda simplemente utilizando los datos contenidos en el índice. En consecuencia, algunas entradas de índice (y los registros de datos correspondientes) pueden descartarse sin que el sistema tenga que leer la tabla directamente.

A continuación, el sistema necesita leer los registros de datos de la tabla correspondientes a las entradas de índice restantes. Sólo entonces puede determinarse si un registro de datos satisface también el resto de la consulta de búsqueda, es decir, si pertenece a la lista de aciertos. El tiempo requerido para leer todos los registros de datos es largo, en comparación con el que se requiere para leer el índice.

Por consiguiente, debería intentarse definir el índice de manera que el número de registros de datos que debe leerse de la tabla no sea muy superior al número de registros que realizan la condición de búsqueda. Este tipo de índice es conocido como índice selectivo, dado que lleva a cabo la mayor parte de la selección para la consulta para búsqueda.

Si se están utilizando las características "Cliente" y "Producto" en el nivel de objeto, el sistema trasladará automáticamente los documentos de facturación desde SD hasta COPA con ese nivel de detalle. Por lo tanto, cuando el sistema busca el número de objeto PA para una posición de documento de facturación, los valores de las características "Cliente" (KNDNR) y "Producto" (ARTNR), se encuentran en el comando SELECT. Ambas características poseen una gran cantidad de valores en la tabla de objeto (son campos selectivos en la tabla de objeto). En consecuencia, el índice secundario MANDT, AKTBO, KNDNR, ARTNR, BUKRS, WERKS, VTWEG es también selectivo, y es posible determinar el número de objeto PA rápidamente.

SELECT * FROM CE4xxxx

WHERE AKTBO = "X"

AND KNDNR = "          "

AND ARTNR = "                           "

AND FKART = fixed value

AND (el resto de características especificadas)

El problema con el que nos encontramos es que los campos selectivos independientes (en este caso puede tratarse del grupo de clientes y el sector), están especificados en la selección pero no se encuentran en el índice secundario utilizado. Por otro lado, los campos menos selectivos comparativamente -- MANDT (normalmente un valor), AKTBO (siempre "X"), KNDNR y ARTNR (siempre en blanco), BUKRS, WERKS y VTWEG (normalmente sólo unos cuantos valores distintos) -- están contenidos en el índice secundario. Cuando el sistema lee este índice (scan rango de índices), tiene que leer también todos los registros de la tabla de objetos que contienen los valores especificados para MANDT, AKTBO, KNDNR, ARTNR, BUKRS, WERKS, y VTWEG. En el peor de los casos, podría tener que leer incluso toda la tabla de objetos. En consecuencia, puede ser que el sistema lea demasiado, y entonces la consulta sea extremadamente lenta. Esto a su vez incide considerablemente en los tiempos de ejecución para los documentos de facturación.

Si el sistema utiliza las características "Cliente" y "Producto" en el nivel de objeto, se debe utilizar un índice que contenga los campos MANDT, AKTBO, KNDNR y ARTNR. Por otro lado, si no se está utilizando "Cliente" y "Producto", y si el grupo de clientes (KDGRP) y el sector (SPART) son las características independientes, será mucho más lógico utilizar un índice con los campos MANDT, AKTBO, KDGRP y SPART. Por lo tanto, para crear un índice secundario adecuado, se necesita saber la jerarquía lógica de las características de su sociedad PA.

A continuación examinaremos el caso de una sociedad PA que tiene el cliente y el producto en el nivel de objeto, pero en la que la planificación se realiza en el grupo de clientes (KDGRP) y en el nivel (SPART) de sector. También en este caso, el índice secundario indicado anteriormente (MANDT, AKTBO, KNDNR, ARTNR), es adecuado para trasladar documentos de facturación.

Sin embargo, al crear documentos plan en un nivel superior, pueden aparecer problemas de rendimiento cuando el sistema intenta buscar los números de objeto. Para ello, el sistema necesita leer todos los registros de la tabla de objetos en los que los campos KNDNR y ARTNR estén en blanco. Si existe una gran cantidad de registros, el rendimiento empeora considerablemente.

Un problema similar surge cuando se trabaja en el nivel cliente/producto de la CO-PA analítica y estas características no son utilizadas en la CO-PA contable.

En el ejemplo anterior (datos reales en el nivel cliente/producto y planificación en el nivel cliente/grupo/sector), un índice secundario consistente en MANDT, AKTBO, KNDNR, ARTNR, KDGRP, SPART sería suficiente. Si se requieren también objetos PA en niveles superiores (p. ej., debido al subreparto del centro de coste), deberá ampliarse de nuevo este índice.

No es oportuna la creación de índices adicionales (p. ej. un índice 1 con MANDT, AKTBO, KNDNR, ARTNR y un índice 2 con MANDT, AKTBO, KDGRP, SPART) en lugar de ampliar el primer índice. Dado que la condición de selección para buscar el número de objeto PA está siempre especificada completamente, el sistema siempre utiliza el mismo índice.

SAP recomienda encarecidamente substituir el ejemplo SAP de índice secundario (código de índice 001), por un índice secundario optimizado según sus circunstancias particulares.