Errores comunes en el desarrollo de Bases de datos: Tercera Parte - La Oficina de Proyectos de Informática

viernes, 30 de noviembre de 2012

Errores comunes en el desarrollo de Bases de datos: Tercera Parte


Presentamos la tercera entrega de la serie "Errores comunes en el desarrollo de bases de datos", describiendo 5 antipatrones adicionales de programación, que son: Utilizar SELECT * de forma indiscriminada, Utilizar INSERT sin especificar una lista de columnas (Campos), Utilizar NULL como un valor ordinario y viceversa, Utilizar aliases de tablas sin significado funcional, Incluir lógica de interfaz gráfica (presentación) en la Base de datos.

Esta lista no es limitativa, ¿Considera usted que existe algún error que deba agregarse a la lista?, le 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).

Presentamos a continuación la tercera parte de "Errores comunes en el desarrollo de bases de datos":

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: Segunda Parte
>> Errores comunes en el desarrollo de Bases de datos
>> Errores comunes de programación: Segunda Parte
>> 5 errores comunes de programación

Tercera parte de la serie “Errores comunes en el desarrollo de bases de datos”

11.- Utilizar SELECT *

El utilizar SELECT * para obtener un gran volumen de datos, sin analizarlo es muy ineficiente, pués quizas sólo se necesite un subconjunto de los datos. Por ejemplo, considérese lo siguiente:

SELECT * FROM dato_cliente WHERE tipo_cliente = 1

¿Que ocurriría si se necesita sólo la lista de teléfonos primario del cliente y la tabla "dato_cliente" posee 80 columnas?, ¿no sería ineficiente obtener todos esos datos de la base de datos cuando se requiere sólo uno?
En este caso, identifique en la lógica del diseño el dato que se requiere obtener y escriba la consulta de forma apropiada, por ejemplo:

SELECT telefono_primario FROM dato_cliente WHERE tipo_cliente = 1

12.- Utilizar INSERT sin especificar una lista de columnas (Campos)

La instrucción INSERT puede utilizarse de dos formas, una sin especificar los nombres de las columnas en las cuales se están insertando los datos, y una segunda forma en que se especifican las columnas y los valores. A continuación un ejemplo:

Especificar sólo valores:
INSERT INTO cliente VALUES (124, 1, 'Jose', 'Ramon', 'Perez', 'Herrera')

Especificar columnas y valores:
INSERT INTO cliente (id_cliente, tipo_cliente, primer_nombre, segundo_nombre, primer_apellido, seguno apellido) VALUES (124, 1, 'Jose', 'Ramon', 'Perez', 'Herrera')

Si utilizamos la primera forma, ¿Que ocurriría con los Procedimientos existentes si se agrega una columna a la tabla?, ¿Que ocurriría si se cambia el ordén de las columnas?, o ¿Que ocurriría si la tabla "cliente" en ambiente de desarrollo no está homologada con la del ambiente de pruebas o producción?.

Por ende, es preferible utilizar la segunda opción, la cual es independiente de la estructura de la tabla.

13.- Utilizar NULL como un valor ordinario y viceversa

Muchos desarrolladores cometen el error de pensar que el comportamiento de "NULL" es igual que en la mayoría de los lenguajes de programación.

A diferencia de otros lenguajes, SQL trata los "NULL" como valores especiales, distintos de cero, falso o una cadena de caracteres (String) vacía, al menos para la mayoría de las marcas de bases de datos. Sin embargo, para añadir más a la confusión, en el caso de Oracle y Sybase, "NULL" es exactamente lo mismo que una cadena (String) de longitud cero.

Por ejemplo, las siguientes expresiones son incorrectas para obtener los valores NULL de una tabla:

SELECT * FROM cliente WHERE direccion = NULL
SELECT * FROM cliente WHERE direccion <> NULL

La condición WHERE sólo se satisface cuando la expresión es "true", sin embargo, una comparación con "NULL" en SQL nunca es "true" siempre es "desconocido" (unknown).

Adicionalmente, la siguiente expresión no retornará columnas cuyo valor sea NULL

SELECT * FROM cliente WHERE tipo_cliente <> "1"

Está expresión retornará valores distintos de 1 pero también distintos de NULL, pués la comparación distinto de NULL no devolverá TRUE.

Para superar este error, es necesario entender que NULL escapa de la lógica tradicional de verdadero o falso (true o false), añadiendo el "desconocido" como un tercer valor.

Es necesario utilizar expresiones como la siguiente:

SELECT * FROM cliente WHERE direccion IS NULL
SELECT * FROM cliente WHERE direccion IS NOT NULL


Para casos como el del tipo de cliente, se puede usar la expresión DISTINC, de la siguiente forma:

SELECT * FROM cliente WHERE tipo_cliente DISTINC FROM "1"

Esta expresión si retornará los casos en los que tipo_cliente sea null.

14.- Utilizar aliases de tablas sin significado funcional

Se considera un antipatrón en el desarrollo de base de datos, el utilizar en consultas SQL aliases de tablas sin significado lógico o funcional, por ejemplo:

SELECT nombre, direccion, telefonos
       FROM empleado tabla1,
                   direccion_habitacion tabla2,
                   telefono_personal tabla3

Esto dificulta la lectura de instrucciones SQL más largas y de utilizarse estos aliases, conduciría a código difícil de entender por otra persona distinta al que lo desarrolló.

En su lugar, si han de utilizarse aliases, deben tener un nombre que guarde relación con el contenido de la tabla, por ejemplo en el caso anterior simplemente "empleado", "direccion" y "telefono".

15.- Incluir lógica de interfaz gráfica (presentación) en la Base de datos

Se considera un antipatron el utilizar la base de datos para algo que no sea asegurar el acceso de los datos de la capa superior, en este caso la de lógica de negocio.

Este antipatron tiende a presentarse cuando los programadores dan formato de presentación a los datos en los procedimientos de base de datos en lugar de hacer esto en la capa que corresponde, en este caso las capas de aplicación superiores. Un ejemplo de este antipatron es el siguiente:

SELECT id_cliente, 
               nombre_cliente, 
               CASE tipo_cliente
                      WHEN 1 Then "Persona"
                      WHEN 2 Then "Empresa"
                      WHEN 3 Then "Organización no Gubernamental"
                      WHEN 4 Then "Entidad Gubernamental"
FROM cliente

En este caso, el programador está utilizando la base de datos para preparar el conjunto de datos, en la forma en que necesita mostrarlos al usuario.

Instrucciones como esta pueden quedar obsoletas fácilmente  debido al alto grado de acoplamiento entre la capa de datos y la funcionalidad de aplicación. Asimismo, este estilo de programación impide que los procedimientos almacenados sean reusables.

En su lugar, el programador debe realizar cualquier conversión que necesite en los datos en la capas de aplicación (lógica de negocio).

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 Segunda Parte

¿Interesado en libros sobre desarrollo de bases de datos?



























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)



Otros artículos en “La Oficina de Proyectos de Informática”

Gestión de desarrollo de software

>>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

>> Los 5 valores de la programación extrema

>> 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

Otros temas

>> 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)

Gerencia de Proyectos

>> Lo Urgente y lo importante en la Gestión 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

>> Plantilla para documentar Lecciones Aprendidas

>> Como hacer el seguimiento de los riesgos en proyectos

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Las reuniones de trabajo: más productividad, menos reuniones

>> El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer

>> Como lidiar con implicados (stakeholders) problemáticos

>> Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnología de información (TI)

No hay comentarios :

Publicar un comentario

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.