lunes
abr302007
Los diez errores más comúnes en el diseño de una BD
lunes, abril 30, 2007 at 3:39PM
Un poco off-topic este enlace pero creo que es bastante interesante para la mayoría de los desarolladores que consultan este portal. Louis Davidson es un experto en el diseño de Base de Datos y es autor del libro SQL Server 2005 Database Design and Optimization en el artículo aquí enlazado presenta los diez errores más comunes en el diseño de una BD que el ha detectado a lo largo de su experiencia:
En mi experiencia la mayoría de los desarrollos donde he trabajado presentan algunas de estas deficiencias en su base de datos. Creo yo que en muchos de los casos es porque se deja a un programador diseñar la base cuando debe ser haber un DBA involucrado en el proceso. Se que muchos proyectos no pueden pagar el sueldo de un DBA en exclusivo pero creo que al menos debe haber un DBA por organización que supervise el diseño elaborado por los programadores, lo mejore y le de su visto bueno.
Con las bases de datos pasa como con el diseño web, cuando se deja en manos de un programador el resultado puede ser un desastre e imagino que la mayoría de ustedes ha tenido que lidiar con chapuzas como una tabla totalmente desnormalizada (digo a veces está bien desnormarlizar para ganar en desempeño pero hay límites) y que necesita de 5 o más campos para tener una llave compuesta (y dile adios a tu idea de usar un ORM para la capa de datos), o una tabla con 20 campos que se llaman campo1, campo2, .. campoN y que nadie en la organización sabe que diablos es el campo7 o quién era el encargado de actualizarlo pero sin él tu aplicación no funciona, en fin no seguiré descargando mi frustración aquí :P . En mi opinión una forma de evitarle frustraciones a los otros programadores es que, dado que las empresas no van a querer pagar un DBA para auxiliarte en el 70% de los casos,nosotros nos documentemos con artículos como el de Louis para realizar un mejor trabajo que programar no es solo usar Spring o el último patrón de diseño.
- Mala planeación del diseño
- Ignorar la normalización
- Estándares de nomenclatura deficientes
- Falta de documentación
- Una sola tabla para guardar todos los valores del dominio
- Usar columnas GUID como la única llave de una tabla
- No usar las funcionalidades SQL para preservar la integridad de los datos
- No usar Stored Procedures para acceder a los datos
- Intentar construir objetos genéricos en los stored procedures
- Falta de pruebas
En mi experiencia la mayoría de los desarrollos donde he trabajado presentan algunas de estas deficiencias en su base de datos. Creo yo que en muchos de los casos es porque se deja a un programador diseñar la base cuando debe ser haber un DBA involucrado en el proceso. Se que muchos proyectos no pueden pagar el sueldo de un DBA en exclusivo pero creo que al menos debe haber un DBA por organización que supervise el diseño elaborado por los programadores, lo mejore y le de su visto bueno.
Con las bases de datos pasa como con el diseño web, cuando se deja en manos de un programador el resultado puede ser un desastre e imagino que la mayoría de ustedes ha tenido que lidiar con chapuzas como una tabla totalmente desnormalizada (digo a veces está bien desnormarlizar para ganar en desempeño pero hay límites) y que necesita de 5 o más campos para tener una llave compuesta (y dile adios a tu idea de usar un ORM para la capa de datos), o una tabla con 20 campos que se llaman campo1, campo2, .. campoN y que nadie en la organización sabe que diablos es el campo7 o quién era el encargado de actualizarlo pero sin él tu aplicación no funciona, en fin no seguiré descargando mi frustración aquí :P . En mi opinión una forma de evitarle frustraciones a los otros programadores es que, dado que las empresas no van a querer pagar un DBA para auxiliarte en el 70% de los casos,nosotros nos documentemos con artículos como el de Louis para realizar un mejor trabajo que programar no es solo usar Spring o el último patrón de diseño.
in otro
otro