Trabajando en muchos proyectos para organismos privados y públicos he visto una y otra vez cómo los sistemas llegan a un punto extremo donde los problemas abundan y las soluciones escasean.
Desafortunadamente, muchos piensan que el problema de los sistemas inestables y costosos de mantener es solo un tema de programación.
La realidad es que el problema casi siempre viene originado por una mala arquitectura, malas prácticas de programación y malos diseños de bases de datos.
Enfocándome en el diseño de bases de datos, un mal diseño complejiza enormemente todo el sistema. No soy experto en bases de datos, pero como desarrollador de sistemas empresariales, el diseño de bases de datos relacionales debe ser un conocimiento básico y fundamental.
Me sorprende encontrar continuamente bases de datos con graves problemas de normalización, graves problemas de inconsistencia de datos, nombres de tablas y columnas incomprensibles o totalmente confusas, etc. Ni hablar del mal uso de los tipos de datos o la ausencia de los índices mínimos para acelerar las principales búsquedas. Posiblemente tampoco exista un plan de backup y mucho menos un plan de restauración testeado. ¿Y la seguridad? Nosé, hay un guardia en la entrada del edificio.
Una situación común es que se crea una tabla o campo con cierto nombre, luego se utiliza en diferentes partes del código. Pasa el tiempo y se le agregan nuevos campos para cubrir nuevos requerimientos. Tiempo después, el equipo se da cuenta que el nombre ya no es representativo. La tabla que se llamaba Ventas, ahora también almacena las Compras, y se prevé que posiblemente también almacene otros comprobantes como Remitos, Notas de crédito, etc.
Un nombre más representativo debería ser Comprobantes, incluyendo un campo discriminador que determine el Tipo de comprobante. Pero el equipo se resiste a cambiar de nombre o crear una nueva tabla, argumentando que también debería actualizar el código de la aplicación, las vistas y los procedimientos almacenados dependientes, y eso es una tarea muy compleja.
Es cierto, es una tarea compleja. Es un cambio que puede “romper” muchas cosas. Pero es un cambio importante para mantener la salud del sistema. Si no lo hacemos, estamos ampliando los problemas futuros de mantenimiento. Empezamos a complicar las cosas. Creamos la primer bola de nieve que irá creciendo.
Alguien preguntará:
“¿Qué hago con los sistemas externos que dependen de esa base de datos?”
En primer lugar no debería tener sistemas externos que dependen directamente del esquema de la base de datos. ¿Donde quedaron los web services y la interoperabilidad? Si este es el caso, quizás las vistas o sinónimos de bases de datos puedan ayudar a disminuir el alto acoplamiento.
Conclusión:
Se necesita coraje y una visión de sistema saludable a largo plazo para saber que ciertos cambios son posibles y necesarios en el momento oportuno y si no se atienden, se convierten en una enfermedad que nosotros mismos creamos.
También hay que saber que existe mucha bibliografía, documentación, blogs y varias herramientas para refactoring de bases de datos. Es cuestión de conocerlas y saber usarlas cuando se necesitan.
Incluyo aquí algunos links interesantes sobre refactoring y deployment de bases de datos:
- The Process of Database Refactoring: Strategies for Improving Database Quality
http://www.agiledata.org/essays/databaseRefactoring.html - Refactoring Databases: Evolutionary Database Design
http://www.ambysoft.com/books/refactoringDatabases.html - First Experience with Visual Studio 2008 Database Edition
http://peterkellner.net/2009/01/17/visual-studio-database-edition-review-sqlserver2008/
En futuros posts intentaré dedicar tiempo a los proyectos de bases de datos para Visual Studio.
Saludos, Gus.
No hay comentarios:
Publicar un comentario