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

PMOinformatica.com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología.

Síguenos en:

viernes, 30 de noviembre de 2012

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

Imagen de: Picasa Web Albums

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

>> Siguiente Artículo: El Objeto Todopoderoso

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