Mr. Solís: Buenos días Ryan, quiero mostrarte el diagrama de base de datos.

Ryan: OK, es el diagrama del sistema de recursos humanos, no?

Mr. Solís: Exacto!, quiero que me des tu opinión sobre unos temas

Se sientan y comienzan a ver el diagrama de base de datos

Ryan: Mr Solís, aquí veo una tabla IMPRENTA. ¿Qué tiene que ver una imprenta con RRHH?

Mr. Solís: Mmm, que raro, no tiene nada que ver…..

Luego de cinco minutos…

Mr. Solís: Ah!, no es IMPRENTA, es IMP RENTA (Impuesto Renta)

Ryan: PLOP!

Moraleja: Usen nombres claros y que no se presenten a confusiones!

La comunicación entre los miembros de un proyecto es muy importante y si no es buena o no se realiza en el momento adecuado traerá consigo una serie de inconvenientes. Por ejemplo: Si un programador se entera tardíamente de alguna modificación de la estructura de la base de datos, esto traerá: incomodidad, bugs y demoras. Por ello, es necesario establecer políticas sobre como y quien debe informar a los interesados de algún cambio en la base de datos. Si no existen políticas claras, documentadas y que estén bien comprendidas todo sera un gran desorden.

Otros problemas tienen que ver con el ambiente de base de datos y suceden con mucha frecuencia. Algunos ejemplos pueden ser resumidos con estos comentarios:

• No puedo probar mi código/funcionalidad porque hay data incoherente en la base de datos
• No se porque la aplicación se cayo cuando la llevamos a producción
• ¡No puedo seguir!, la base de datos esta lenta. Y alguien responde: es que Juan Peréz esta probando un proceso pesado
• La aplicación esta muy lenta en producción. Hay que ver la manera de mejorar el tiempo de respuesta pero primero llena la base de datos de prueba con mas registros
• ¿Alguien apagó la PC donde esta la base de datos?

La propuesta que más me agrada para definir el ambiente de base de datos, es la de Scott W. Amber. El lo denomina database sandboxes:

Cada programador cuenta con una base de datos propia (development sandbox) donde puede realizar todo lo que desee, de preferencia esta base de datos debe estar en su propia PC. Por otro lado se debe tener una base de datos para integración (project integration sandbox), donde los programadores puedan realizar pruebas de integración.

El proyecto necesitará una base de datos especial (demo sandbox)) para mostrar a sus stakeholders un demo de la aplicación o para realizar pruebas de aceptación. Finalmente, se debe tener una base de datos (pre-production Test/QA sandbox) para realizar pruebas (QA) y para probar la aplicación con data similar a la que procesará/usará en producción.

Una vez establecido este ambiente y luego que el equipo ha asimilado la forma de trabajo, sería muy interesante (y un reto también) intentar aplicar las propuestas de Evolutionary/Agile Database Development.