---- Audio 1
Existen motivos para utilizar todavía el almacenamiento por filas en una tabla, por ejemplo: si se accede a una tabla predominantemente mediante declaraciones en lenguaje de manipulación de datos (DML) en el tiempo, por ejemplo mediante update, insert o delete. Esta no puede ser una tabla de aplicaciones en la que posteriormente deseemos realizar análisis, por lo tanto principalmente las tablas técnicas de SAP son elegibles para el almacenamiento por filas. Los ejemplos incluyen tablas para el procesamiento de actualizaciones correspondientes al paquete STSK o para el procesamiento de llamadas a función remota RFC correspondientes al paquete SRFC. Normalmente se accede a estas tablas con un SELECT SINGLE
---- Audio 2
Al diseñar la aplicación debemos considerar las siguientes preguntas:
- ¿Existen sistemas con un sistema de base de datos diferente en nuestro entorno de trabajo o en el entorno del cliente?
- ¿Cuán fundamentales son las funciones específicas de la base de datos para nuestra aplicación?
- ¿Está involucrada la calidad central de la aplicación?
- ¿El desarrollo en SAP HANA se llamará únicamente a través de aplicaciones basadas en ABAP o también a través de otros canales?
---- Audio 3
Pueden ocurrir problemas cuando asumimos que un ordenamiento determinado es llevado a cabo en la secuencia de un programa ABAP. Este es el caso por ejemplo de cuando trabajamos con tablas internas y ejecutamos la función BINARY SEARCH, la cual tiene como requisito que la tabla interna se encuentre previamente ordenada por el campo o campos a partir de los cuales se realizará la búsqueda binaria.
Podemos encontrarnos con sorpresas en la lista de salida de datos si de repente no aparecen en el orden de clasificación deseado. En conclusión no debemos confiar en los ordenamientos implícitos, si necesitamos una clasificación específica de los datos, cuando accedemos a una base de datos, debemos utilizar la adición ORDER BY explícitamente.
---- Audio 4
Aunque la adición INTO CORRESPONDING FIELDS OF selecciona solo las columnas que también están en la tabla interna de destino, cuando se especifica asterisco(*) se requiere un esfuerzo adicional para comparar nombres en la interface de la base de datos. Por lo tanto esta adición solo debe usarse con moderación y para conjunto de datos de resultado más grande porque el esfuerzo involucrado en la comparación de nombres puede ser relativamente alto para declaraciones SELECT muy rápidas
---- Audio 5
Para formular las clausulas WHERE estas son nuestras principales recomendaciones:
El operador igual(=) o el operador EQUAL y los enlaces AND siempre son compatibles de manera eficiente en el índice, es decir el optimizador puede reducir el esfuerzo entrada/salida siempre que sea técnicamente posible.
Una lista de IN también cabe en esta categoría porque representa en principio un múltiple igual para la columna, por lo tanto debemos utilizar las condiciones igual(=) siempre que sea posible.
Debemos evitar las condiciones negativas como distinto(< >), NOT EQUAL o NO porque no se pueden admitir de manera eficiente en el índice, si es posible debemos reescribir tales condiciones como condiciones positivas, si esto no es posible aun igual debemos especificar las condiciones en la condición WHERE y no omitirlas por completo; esta es la única forma en que se seleccionaran los registros de datos requeridos, de lo contrario leemos registros innecesarios que luego debemos eliminar en el programa ABAP lo que contradice la primera regla de oro, sino especificamos todos los campos en el índice debemos asegurarnos de incluir la sección inicial del indice en la condición WHERE, de lo contrario el uso de un índice no es posible en muchos casos