En la semana anterior, publicamos un artículo titulado “Errores comunes en el desarrollo de bases de datos”, en el cual se exponían una serie de errores comunes y sus alternativas. Presentamos a continuación la segunda parte de esa serie, presentando errores comunes adicionales, como lo son: Hacer caso omiso de los índices a la hora de escribir consultas que relacionen tablas, no utilizar sentencias preparadas, usar instrucciones DISTINCT para no mostrar filas duplicadas, utilizar GROUP BY y HAVING para filtrar filas (en lugar de WHERE), colocar un cursor o consulta dentro de un ciclo y no utilizar herramientas para analizar el desempeño de consultas y procedimientos.
Este artículo fue elaborado con base a los comentarios recibidos de la comunidad y fuentes de información consultadas. Esta lista no es limitativa, seguramente el lector podrá pensar en muchos más errores comunes, ¿Considera que existe algún error que deba agregarse a la lista?, les invitamos a opinar en el foro de discusión del artículo (Tome en cuenta que los comentarios son moderados por lo que pueden tardar en ser publicados).
Acerca de artículos anteriores de esta serie
Referencia Principal
>> ATM Blog. 5 Database Development Mistakes Made by Application Developers.
>> Plamen Ratchev para simple-talk. Ten Common SQL Programming Mistakes
Otros artículos en “La Oficina de Proyectos de Informática”
Gestión de desarrollo de software
>> Errores comunes en el desarrollo de Bases de datos
>> 5 Herramientas para la automatización de pruebas de software
>>Errores comunes de programación: Segunda Parte
>>5 errores comunes de programación
>>10 actividades críticas a incluir en todo plan de desarrollo de un software
Este artículo fue elaborado con base a los comentarios recibidos de la comunidad y fuentes de información consultadas. Esta lista no es limitativa, seguramente el lector podrá pensar en muchos más errores comunes, ¿Considera que existe algún error que deba agregarse a la lista?, les invitamos a opinar en el foro de discusión del artículo (Tome en cuenta que los comentarios son moderados por lo que pueden tardar en ser publicados).
Acerca de artículos anteriores de esta serie
¿Quiere saber más sobre errores comunes de programación, le invitamos a revisar otros artículos de esta serie en el blog.
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
Sin más preámbulo presentamos a continuación la segunda parte de la serie “Errores comunes en el desarrollo de bases de datos”.
6.- Consulta (Query) que no toma en cuenta los índices definidos
Al escribir consultas (SELECT) que impliquen la unión de varias las tablas, lo recomendado es utilizar en la clausula WHERE columnas que posean índices, dado que esto mejora el desempeño de estas operaciones. Parece obvio, sin embargo, es común que se ignore cuando se están realizando consultas de mayor complejidad que impliquen la unión de varias tablas. Realizar un WHERE por columnas no indexadas ocasiona que el manejador de base de datos tarde más tiempo en obtener las filas relacionadas de una tabla a otra.
Otra situación no recomendable es realizar un WHERE con funciones sobre columnas que poseen índices, por ejemplo:
WHERE LEFT(cliente, 1) o
WHERE DATEPART (Year, fecha_compra) = 2012 AND
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación
Sin más preámbulo presentamos a continuación la segunda parte de la serie “Errores comunes en el desarrollo de bases de datos”.
6.- Consulta (Query) que no toma en cuenta los índices definidos
Al escribir consultas (SELECT) que impliquen la unión de varias las tablas, lo recomendado es utilizar en la clausula WHERE columnas que posean índices, dado que esto mejora el desempeño de estas operaciones. Parece obvio, sin embargo, es común que se ignore cuando se están realizando consultas de mayor complejidad que impliquen la unión de varias tablas. Realizar un WHERE por columnas no indexadas ocasiona que el manejador de base de datos tarde más tiempo en obtener las filas relacionadas de una tabla a otra.
Otra situación no recomendable es realizar un WHERE con funciones sobre columnas que poseen índices, por ejemplo:
WHERE LEFT(cliente, 1) o
WHERE DATEPART (Year, fecha_compra) = 2012 AND
DATEPART (Month, fecha_compra) = 2
Esto ocasiona que el manejador de base de datos no pueda utilizar los índices que existen sobre las columnas, incrementando el tiempo de ejecución. En su lugar, es preferible escribir las instrucciones de la siguiente forma:
WHERE cliente LIKE ‘1%’
WHERE fecha_compra >= '20120201' AND
Esto ocasiona que el manejador de base de datos no pueda utilizar los índices que existen sobre las columnas, incrementando el tiempo de ejecución. En su lugar, es preferible escribir las instrucciones de la siguiente forma:
WHERE cliente LIKE ‘1%’
WHERE fecha_compra >= '20120201' AND
fecha_compra < '20120301';
De esta forma, los índices sobre “cliente” y “fecha_compra” son utilizados.
7.- Usar DISTINCT, GROUP BY o HAVING en lugar de WHERE para la unión entre tablas
El DISTINCT suele ser un artificio utilizado para solucionar problemas con consultas que están retornando registros duplicados, sin embargo, no es la solución más óptima de resolver ese tipo de situaciones y dificulta el mantenimiento de aplicaciones de bases de datos en el tiempo. Lo recomendable, es revisar las relaciones entre tablas, identificar porque se están retornando duplicados y luego ajustar la programación (y de ser necesario el diseño) para que esto no suceda.
La instrucción DISTINCT no es la forma más optima de no retornar duplicados y ante el crecimiento de la cantidad de filas puede convertirse en un problema.
Otro error común es utilizar GROUP BY y HAVING, en lugar de WHERE, por ejemplo:
SELECT cliente.cod_cliente, cliente.nombre, cliente.tipo_cliente dirección.direccion
FROM cliente, dirección
GROUP BY cliente.cod_cliente
HAVING cliente.tipo_cliente = 1
En lugar de:
SELECT cliente.cod_cliente, cliente.nombre, cliente.tipo_cliente dirección.direccion
FROM cliente, dirección
WHERE cliente.cod_cliente = dirección.cod_cliente AND
cliente.tipo_cliente = 1
Las instrucciones SQL que utilizar WHERE y JOIN para las relaciones entre tablas se ejecutan mucho más rápido que las que utilizan GROUP BY y HAVING.
8.- Colocar un cursor o consulta en un ciclo (WHILE, FOR o LOOP)
De esta forma, los índices sobre “cliente” y “fecha_compra” son utilizados.
7.- Usar DISTINCT, GROUP BY o HAVING en lugar de WHERE para la unión entre tablas
El DISTINCT suele ser un artificio utilizado para solucionar problemas con consultas que están retornando registros duplicados, sin embargo, no es la solución más óptima de resolver ese tipo de situaciones y dificulta el mantenimiento de aplicaciones de bases de datos en el tiempo. Lo recomendable, es revisar las relaciones entre tablas, identificar porque se están retornando duplicados y luego ajustar la programación (y de ser necesario el diseño) para que esto no suceda.
La instrucción DISTINCT no es la forma más optima de no retornar duplicados y ante el crecimiento de la cantidad de filas puede convertirse en un problema.
Otro error común es utilizar GROUP BY y HAVING, en lugar de WHERE, por ejemplo:
SELECT cliente.cod_cliente, cliente.nombre, cliente.tipo_cliente dirección.direccion
FROM cliente, dirección
GROUP BY cliente.cod_cliente
HAVING cliente.tipo_cliente = 1
En lugar de:
SELECT cliente.cod_cliente, cliente.nombre, cliente.tipo_cliente dirección.direccion
FROM cliente, dirección
WHERE cliente.cod_cliente = dirección.cod_cliente AND
cliente.tipo_cliente = 1
Las instrucciones SQL que utilizar WHERE y JOIN para las relaciones entre tablas se ejecutan mucho más rápido que las que utilizan GROUP BY y HAVING.
8.- Colocar un cursor o consulta en un ciclo (WHILE, FOR o LOOP)
Suponga que se define un cursor para recorrer una tabla por medio de un ciclo y luego dentro de la misma se define otro cursor para recorrer otra tabla relacionada, la ejecución de este programa será más ineficiente que definir una consulta que realicé la unión de registros relacionados en ambas tablas y se ejecute un solo cursor para recorrerla.
Adicionalmente, si se define un cursor para recorrer una tabla por medio de un ciclo, para luego en cada iteración realizar una consulta (SELECT) sobre otra tabla relacionada, la ejecución también será más ineficiente que realizar la instrucción una sola vez al principio.
Por supuesto, existen otras consideraciones para optimizar las consultas, por ejemplo no recorrer toda la tabla cuando se necesita sólo un registro o algunos de ellos, en estos casos lo recomendable es definir el cursor sobre consultas donde se filtren los datos necesarios (por ejemplo por medio de WHERE).
9.- No utilizar sentencias preparadas (Prepared Statements)
Una sentencia preparada, es cuando se compila una consulta, exceptuando los datos para ser usados, los cuales son suministrados posteriormente al momento de invocarlo.
El no utilizar sentencias preparadas ocasiona que el manejador de base de datos deba compilarlo cada vez que lo encuentre. Al utilizar sentencias preparadas, se le permite al manejador compilar la sentencia y su plan de ejecución registrándoles en memoria.
10.- No realizar análisis de desempeño en las consultas
Adicionalmente, si se define un cursor para recorrer una tabla por medio de un ciclo, para luego en cada iteración realizar una consulta (SELECT) sobre otra tabla relacionada, la ejecución también será más ineficiente que realizar la instrucción una sola vez al principio.
Por supuesto, existen otras consideraciones para optimizar las consultas, por ejemplo no recorrer toda la tabla cuando se necesita sólo un registro o algunos de ellos, en estos casos lo recomendable es definir el cursor sobre consultas donde se filtren los datos necesarios (por ejemplo por medio de WHERE).
9.- No utilizar sentencias preparadas (Prepared Statements)
Una sentencia preparada, es cuando se compila una consulta, exceptuando los datos para ser usados, los cuales son suministrados posteriormente al momento de invocarlo.
El no utilizar sentencias preparadas ocasiona que el manejador de base de datos deba compilarlo cada vez que lo encuentre. Al utilizar sentencias preparadas, se le permite al manejador compilar la sentencia y su plan de ejecución registrándoles en memoria.
10.- No realizar análisis de desempeño en las consultas
En la actualidad la gran mayoría de los manejadores de bases de datos ofrecen la posibilidad de analizar el desempeño de las consultas y procedimientos almacenados, la intención es programar un plan de ejecución y ver como se desempeña, identificando consultas y bloques de proceso ineficientes para su optimización. Es recomendable hacer uso del análisis de desempeño.
Conclusión
¿Y qué opina usted?, ¿Cuáles son los errores más comunes que ha observado en el desarrollo de bases de datos?, ¿Qué errores agregaría a esta lista? Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica o al feed RSS del Blog.
<<Ir a Primera Parte
Conclusión
¿Y qué opina usted?, ¿Cuáles son los errores más comunes que ha observado en el desarrollo de bases de datos?, ¿Qué errores agregaría a esta lista? Le invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” (http://oficinaproyectosinformatica.blogspot.com) y a suscribirse al blog por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica o al feed RSS del Blog.
<<Ir a Primera Parte
¿Interesado en libros sobre desarrollo de bases de datos?
25 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
19 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
Octubre 2012: Más buscados en desarrollo ágil. >>España >>Latinoamérica
Octubre 2012: Más buscados en gestión de proyectos. >>España >>Latinoamérica
Sección de productos Amazon. >>Visítala
 |  |  |  |
| Transact SQL-DML Funciones y Bases de datos Autor: Rocío Navarro Lacoba >> España (amazon.es)  >> Latinoamérica (amazon.com)  | Código Limpio Autor: Robert C. Martin >> España (amazon.es)  >> Latinoamérica (amazon.com)  | Métodos ágiles y Scrum Autor: Alonso Alvarez García y otros >> España (amazon.es)  >> Latinoamérica (amazon.com)  | Beginning Database Design Autor: Clare Churcher >> España (amazon.es)  >> Latinoamérica (amazon.com)  |
25 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
19 de Octubre 2012: Los Productos de la semana. >>Ver Productos de la Semana
Octubre 2012: Más buscados en desarrollo ágil. >>España >>Latinoamérica
Octubre 2012: Más buscados en gestión de proyectos. >>España >>Latinoamérica
Sección de productos Amazon. >>Visítala
Referencia Principal
>> ATM Blog. 5 Database Development Mistakes Made by Application Developers.
>> Plamen Ratchev para simple-talk. Ten Common SQL Programming Mistakes
Otros artículos en “La Oficina de Proyectos de Informática”
Gestión de desarrollo de software
>> Errores comunes en el desarrollo de Bases de datos
>> 5 Herramientas para la automatización de pruebas de software
>>Errores comunes de programación: Segunda Parte
>>5 errores comunes de programación
>>10 actividades críticas a incluir en todo plan de desarrollo de un software
>> Los pasos para resolver incidentes en el período de estabilización de un desarrollo de software
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
Desarrollo ágil, Scrum y Test Driven Development
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> Plantillas Scrum: historias de usuario y criterios de aceptación
>> El “Test Driven Development” (TDD): Desarrollo y pruebas de software bajo Scrum
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
>> Los Programas de Certificación del Scrum Alliance
>> Preguntas y respuestas sobre Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
Aspectos Generales
>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información
>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)
>> Las reuniones de trabajo: más productividad, menos reuniones
Gerencia de Proyectos
>> Gestión de Proyectos: 5 tareas clave para dirigir la fase de ejecución
>> 5 preguntas y respuestas sobre la identificación de riesgos
>> Como hacer el seguimiento de los riesgos en proyectos
>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012
>> Ambientes de pruebas integrales de software: Buenas prácticas
>> Ambientes de desarrollo de software: Buenas prácticas
>> Algunas prácticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)
>> Las preguntas que debe hacer al encargarse de un proyecto de Tecnología de Información (TI) en ejecución
Desarrollo ágil, Scrum y Test Driven Development
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> Plantillas Scrum: historias de usuario y criterios de aceptación
>> El “Test Driven Development” (TDD): Desarrollo y pruebas de software bajo Scrum
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
>> Los Programas de Certificación del Scrum Alliance
>> Preguntas y respuestas sobre Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
Aspectos Generales
>> Habilidades interpersonales cada vez más demandadas en los profesionales de Tecnologías de Información
>> Las Habilidades y Conocimientos más buscados en el área de Tecnología de Información (TI)
>> Las reuniones de trabajo: más productividad, menos reuniones
Gerencia de Proyectos
>> Gestión de Proyectos: 5 tareas clave para dirigir la fase de ejecución
>> 5 preguntas y respuestas sobre la identificación de riesgos
>> Como hacer el seguimiento de los riesgos en proyectos
>> Plantilla para la Gestión de Riesgos en proyectos: Actualización Octubre 2012
No hay comentarios :
Publicar un comentario