Barra Superior

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:     

lunes, 12 de noviembre de 2012

Errores comunes en el desarrollo de Bases de datos

Imagen de: Picasa Web Albums
Continuando con nuestra serie de artículos de errores comunes en el desarrollo de software, en este artículo presentamos 5 errores comunes en el desarrollo de bases de datos. Consisten en: uso excesivo de claves primarias (Primary Key), normalización inadecuada, uso excesivo de procedimientos almacenados (Stored Procedures), no usar claves primarias y usar “hard delete” en lugar de “soft delete”.

El siguiente es un extracto del artículo “Five common database development mistakes”, publicado en el blog “Software Engineer” de Techrepublic.com, de fecha 30 agosto 2012. Su autor (Justin James) describe algunos errores comunes en el desarrollo de bases de datos y como no cometerlos. Estos errores son independientes del manejador de bases de datos utilizado.

Sin más preámbulo, presentamos a continuación 5 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 de programación: Segunda Parte
>> 5 errores comunes de programación

1.- Uso excesivo de claves primarias (Primary Key)

La clave primaria no debería tener nada que ver con los datos de cada fila, por lo tanto, es recomendable no usar como claves primaria datos de la aplicación o del negocio, concatenaciones o cálculos de estos o valores que tengan algún significado.

Las claves primarias deben ser secuenciales y generadas al azar al momento de la inserción de la fila. Nunca deberían modificarse (sólo debería permitirse en circunstancias muy inusuales).

Deben pertenecer al sistema y ser gestionadas solamente por el sistema, esto con la finalidad que puedan transportarse a otro sistema de forma segura (en caso de migraciones) y que puedan cambiarse los datos de la aplicación sin afectar las relaciones en la base de datos.

2.- Normalización inadecuada

Existen dos extremos, algunos desarrolladores tienen la tendencia de convertir cualquier cosa en una relación, mientras que otros nunca hacen uso de las relaciones. A continuación algunos lineamientos para decidir cuando los datos deberían o no deberían registrarse en otra tabla (de relaciones): 

  • Cuando existen datos que serán compartidos por múltiples filas y los cambios en una deberían afectar las demás, es recomendable mover los datos involucrados a otra tabla. Por ejemplo, los clientes de un catalogo deberían estar separados de sus ordenes.
  • Cuando los datos serán compartidos en múltiples filas, pero los cambios en uno no afectan las demás, entonces es recomendable mantenerlos en la misma tabla. Como alternativa, se pueden separar en otra tabla pero haciendo uso de un esquema de versionamiento de, con la finalidad que las filas relacionadas mantengan sus valores, los datos cambiados se registren en una nueva fila y la clave se actualice en la fila original (Padre).
  • Si los datos pueden ser actualizados o usados de forma separada del resto de la fila, es recomendable colocarlos en una tabla separada, pues tiene más sentido lógico y proporciona mayores ventajas de integridad de datos el bloquear filas en lugar de columnas. 

3.- Uso excesivo de procedimientos almacenados (Stored Procedures)

Los procedimientos automatizados son muy útiles, sin embargo, con nuevas técnicas de vanguardia como el Object Relationship Mapping (ORMs) ya no es necesario depender tanto de ellos como en el pasado.

Los procedimientos almacenados pueden representan una carga importante en el mantenimiento, al no existe forma sencilla de determinar que aplicaciones los están usando, ocasionando que cuando un procedimiento almacenado requiera un cambio mayor lo que se termine haciendo es hacer uno nuevo en lugar de alterar el existente.

Por ende, cuando deba usar un procedimiento almacenado, es necesario asegurar que realmente se justifique. Como regla general lo mejor es usarlos solamente para representar lógica de acceso a datos pero nunca para otra lógica de negocios o aplicación.

4.- No usar claves primarias

Así como existen desarrolladores que hacen uso excesivo de las claves primarias (ver número 1), también existen otros que no creen en ellas, dejando la restricción de dato único a la lógica de programación en base de datos en vistas y procedimientos almacenados, e inclusive en la lógica de aplicación.

El no usar claves primarias contribuye con la proliferación de procedimientos almacenados y vistas innecesarias, pues los desarrolladores experimentan dificultad para evitar que errores esquema de bases de datos (usualmente de desarrollos previos) no afecten las aplicaciones.

5.- Usar “Hard Delete” en lugar de “Soft Delete”

Usar “Hard Delete” puede dificultar el proceso de restaurar datos eliminados por error o al auditar problemas en aplicaciones, con frecuencia siendo necesario restaurar los datos en un servidor separado y revisiones interminables de logs de transacciones. Es por ello, que es recomendable utilizar “Soft delete”, en el cual la fila se hace inactiva en lugar de ser eliminada.

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.

<< Artículo anterior: Errores comunes de programación (2da Parte)
                                                                                                             >> 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)


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:

>> Five common database development mistakes

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


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

>> 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 en la entrada

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.