 |
| 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.
3.- Uso excesivo de procedimientos almacenados (Stored Procedures)
Los procedimientos almacenados 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 existir una 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” 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)
¿Interesado en libros sobre desarrollo de bases de datos?
Referencia:
>> Five common database development mistakes
Artículos relacionados
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):
¿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 almacenados 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 existir una 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” 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)
¿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) 
|
Referencia:
>> Five common database development mistakes
Artículos relacionados
No hay comentarios :
Publicar un comentario