Foro de Cobol
Registrate en el Foro de Cobol y Aporta tus experiencias y conocimientos sobre este lenguaje de programacion, con tu ayuda el foro crecera y todos nos podremos beneficiar de los conocimientos de los demas.

Gracias por entrar a COBOLEROS.ES
Síguenos en Twitter

Consideraciones en construccion DB2

Ver el tema anterior Ver el tema siguiente Ir abajo

Consideraciones en construccion DB2

Mensaje por Coboler@ el Jue Feb 24, 2011 10:32 pm

INTRODUCCIÓN.
En cuanto a consideraciones en construcción tan solo se especifican una serie de normas de programación con DB2. Esta lista es susceptible de ampliación.
Estas normas no sólo son debidas a rendimiento, sino también a mantenibilidad de los programas de la instalación

LISTA DE RECOMENDACIONES Y NORMATIVA.
 Ninguna sentencia SQL debe trabajar con la DCLGEN a nivel 01, las variables host deben referenciarse una a una.
 No se puede utilizar la sentencia ROLLBACK de forma explícita en los programas.
 No se puede utilizar la sentencia COMMIT de forma explícita en los programas. Si el programa necesita realizar COMMIT, bien debido a un proceso elevado de actualizaciones, bien debido a la necesidad de liberar recursos por necesidades de concurrencia, deberá utilizar las rutinas de REARRANQUE preparadas al efecto. En caso contrario, es necesario eliminar dicha sentencia.
 Las sentencias FETCH de un cursor deben contemplar las mismas columnas que se estén recuperando en la SELECT del DECLARE CURSOR y en el mismo orden.
 Los cursores deben cerrarse (CLOSE) antes de fin de programa
 No se debe utilizar la cláusula FOR UPDATE OF en un cursor si las filas recuperadas no van a ser actualizadas por el proceso.
 Las sentencias INSERT deben codificarse completas con los nombres de las columnas DB2 y las variables HOST.
 No se permite la utilización de la sentencia JOIN en los programas. Se recomienda buscar un acceso óptimo a los datos.
 La sentencia SQL SELECT COUNT(*) no debe ser utilizada en los programas para verificar la existencia de filas que cumplan la condición de búsqueda.
 Las sentencias SELECT MAX()/MIN()/SUM()….deben codificarse contemplando el indicador de nulos. Es necesario analizar el campo indicador de nulos cuando el SQLCODE es igual a cero, ya que valores negativos del mismo indican que ninguna ocurrencia cumple la condición. Utilizar este tratamiento en lugar de comprobar el SQLCODE -305.
 No se deben utilizar valores constantes en sentencias SQL, salvo en el caso de la cláusula IN.
 Las HOST-VARIABLES en las sentencias SQL deben codificarse precedidas por dos puntos.
 En todas las sentencias SQL debe controlarse el SQLCODE de forma correcta, teniendo en cuenta que en los errores del sistema DB2 han de utilizarse los párrafos referentes a las rutinas de ABEND, y en los errores de datos debe quedar bien diferenciado que el motivo del error no es debido al sistema DB2 (p.e. +100 o -811 en una select no es debido a un error del sistema DB2). Según la sentencia SQL que se utilice, es necesario controlar el SQLCODE del siguiente modo:
o SELECT-FETCH-UPDATE-DELETE - 0 Y +100
o INSERT  0 Y -803
o OPEN-CLOSE  0
o UPDATE/DELETE WHERE CURRENT OF  0
o SELECT AVG/MAX/MIN  0
o SELECT con más de una fila  0 y -811
Para otros SQLCODE se llamará a la rutina de errores DB2.
 Las sentencias UPDATE que actualicen columnas de una entidad que no han sido modificadas en el proceso del programa deben ser eliminadas. Sí la actualización se lleva a acabo a través de un cursor y no existe ninguna otra actualización mediante éste, debe ser eliminada la cláusula FOR UPDATE OF del mismo.
 Las actualizaciones de las columnas de un índice cluster deben realizarse mediante DELETE-INSERT y no mediante UPDATE
 Los programas que tengan actualizaciones en batch deben hacer uso de las rutinas de COMMIT y REARRANQUE preparadas a tal efecto en la instalación. Y como consecuencia del uso de estas rutinas, no deberán generar ficheros de salida o listados.
 No se permite el uso de SELECT *.
 Se recomienda que en los accesos mediante índice se utilice el máximo número posible de campos que lo componen. Si sólo se usa parte, se discriminan pocos valores y dicho acceso es costoso
 Cuando una rutina DB2 detecta un SQLCODE de error, ha de devolver inmediatamente el control al programa principal, informando del suceso correctamente.
 Todos los atributos de una entidad que se necesiten a lo largo de un programa, deben ser obtenidos mediante un único acceso.
 Las actualizaciones de entidades que pertenecen a otras aplicaciones deben realizarse mediante un programa o rutina proporcionado por la aplicación propietaria de la entidad.
 El SQLCODE debe controlarse inmediatamente detrás de cada instrucción SQL.
 No se deben utilizar sentencias DB2 anidadas (SUBSELECT, …).
 Se recomienda revisar el acceso a la entidad referenciada, ya que obliga al DB2 a realizar un SORT.
 Se recomienda sustituir el CURSOR por una SELECT cuando sólo se recupera una fila
 La actualización mediante la sentencia DELETE o UPDATE no debe actuar sobre más de una fila
 Se deben incluir las primeras columnas del índice en la cláusula WHERE para optimizar el acceso.
 Sustituir las condiciones del tipo A>B OR A=B por A>=B en sentencias SQL. Lo mismo en el caso de <.
 Se recomienda revisar los accesos por Múltiple Index Scan
 No se permite utilizar SELECT CURRENT TIMESTAMP, DATE, TIME.
 Sustituir las condiciones del tipo A ->B por A <=B en sentencias SQL. Lo mismo para -<.
 En procesos batch, las tablas DB2 de bajo volumen y muy accedidas deben copiarse en working al principio de la ejecución del programa.
 No deben utilizarse expresiones aritméticas ni en la sentencia SELECT, ni en la cláusula WHERE de sentencias SQL.
 Se recomienda encarecidamente analizar la sentencia SELECT COUNT(*) intentando cambiarla por una que condicione, además, por los primeros campos del índice, con el fin de agilizar la búsqueda.
 No se permiten en los programas sentencias SQL incompatibles en las diversas ramas de las instrucciones IF o EVALUATE a la hora de evaluar de forma conjunta el SQLCODE
 No se permiten estructuras de condición incorrecta en el control del valor del SQLCODE
 Para verificar la existencia de una fila mediante SELECT, sólo se debe recuperar una columna del índice por el que se está accediendo.
 Las sentencias (SELECT FETCH) utilizadas para verificar la existencia o no de una fila para su posterior actualización (UPDATE/DELETE/INSERT) deben ser eliminadas del código del programa.
 Las sentencias SQL no deben recuperar columnas que no sean utilizadas durante el proceso del programa.
 No se deben utilizar variables de working en sentencias SQL, salvo en casos necesarios. Deben utilizarse los campos de la DCLGEN de la entidad utilizada.
 Todas las actualizaciones de una fila que requieran lectura previa deben realizarse mediante un cursor FOR UPDATE y la actualización WHERE CURRENT OF.
 Las sentencias (SELECT FETCH) utilizadas para verificar la existencia de filas que cumplan la condición de búsqueda para su posterior lectura, deben ser eliminadas y sustituidas por el primer acceso para recuperar datos.
 Los programas que no contengan accesos SQL no deben incluir la SQLCA.
 La cláusula FOR UPDATE OF de un cursor no debe contener más columnas de las que actualiza durante el proceso la sentencia UPDATE …..WHERE CURRENT OF.
 En las actualizaciones mediante DELETE WHERE CURRENT OF, sólo es necesario declarar una columna en la cláusula FOR UPDATE del DECLARE CURSOR.
 En la sentencia SQL SELECT COUNT(*) no se debe contemplar indicador de nulos, solamente debe controlarse el SQLCODE.
 Todas las sentencias SQL que no se usen durante el proceso del programa deben ser eliminadas del mismo.
 Las sentencias SQL que tengan una codificación idéntica deben ser codificadas en un párrafo aparte una sola vez.
 La sentencia DECLARE CURSOR tiene que ser codificada en WORKING STORAGE SECTION y no en PROCEDURE DIVISION ni en LINKAGE SECTION.
 Las sentencias SELECT y FETCH no deben recuperar columnas de las que ya conocemos el valor por estar condicionadas por igual en la cláusula WHERE. Sólo se podrán recuperar cuando la sintaxis de SQL LO REQUIERA, es decir, en el caso de ORDER BY por ellas.
 Las sentencias INCLUDE de tablas que no se utilicen en el programa deben eliminarse.
 Los valores incluidos en la lista de la cláusula IN deben ir separados entre sí al menos por una coma y un blanco.
 En la cláusula Order by de cursores que necesiten reposicionamiento deben incluir todos los campos que en el índice clúster se encuentren situados a la izquierda del campo por el que se quiere ordenar aunque estos campos se condicionen por igual: Esto hace que el DB2 establezca un mejor camino de acceso y, en el 90% de los casos, evita realizar sort.
 Está prohibida la utilización de SQL dinámico en programas.


avatar
Coboler@
Admin

Mensajes : 215
Reputación : 19
Fecha de inscripción : 02/02/2011
Edad : 37
Localización : Madrid

Ver perfil de usuario http://www.coboleros.es

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.