eMartos

Hoy teníamos que implementar un prototipo de importación masiva de hojas Excel a una base de datos MySQL. Se trata de una operación transaccional, pero cada sentencia de inserción o actualización se hacía efectiva en la base de datos, de manera que el rollback se hacía imposible, y un commit era inútil.

Tras una breve búsqueda, encontré este enlace, que propone usar el objeto ResultSet en lugar de lanzar directamente el statement.

Un amigo y colega me pide consejo para determinar qué camino debe seguir el desarrollo de software de su empresa. Al parecer, se están planteando migrar sus aplicaciones (implementadas en MS Access) a una nueva tecnología. La duda que tienen es si seguir la evolución natural, es decir, Visual Basic .NET, o entrar en el mundo web (ya sea de la mano de ASP.NET o de tecnologías alternativas).

En estos casos, antes de hablar de tecnologías es conveniente definir qué utilidad va a tener el producto. El departamento técnico debe hacerse preguntas que ayuden a demarcar el contexto de actuación. ¿Quién va a usar el producto? ¿Para qué? ¿En qué entornos? ¿Va a existir alguna posibilidad (real) de accesos a la aplicación desde varios puntos separados geográficamente?

No obstante, mi amigo tiene ciertos prejuicios sobre las aplicaciones web. Su opinión es que las aplicaciones de peso (contabilidad, gestión administrativa, etc.) no encajan bien en la web. Mi respuesta es que cada vez quedan menos aplicaciones incompatibles con este tipo de entornos. Son utilidades específicas con dos requisitos principalmente: una cantidad considerable de recursos y una rápida interacción con el usuario. Como los datos resultantes de estas aplicaciones suelen ser voluminosos (p.e. un programa de retoque fotográfico), todavía resulta difícil implementar esta funcionalidad en un navegador. Pero si han conseguido que una hoja de cálculo funcione en la web, ¿por qué no una aplicación de gestión? En el caso concreto de mi amigo, además, estamos hablando de intranet y, en menor medida, de extranet, lo cual garantiza velocidades de respuesta bastante decentes. Y hay otro dato a tener en cuenta: el volumen de datos a procesar no es excesivo ni hay una concurrencia de usuarios considerable. Teniendo en cuenta todos estos factores, la opción web parece bastante factible.

Ahora bien, actualmente vivimos una fiebre web que tampoco es sana. "Lo ideal es programarlo todo en web", como le comenta un compañero, no aporta ningún argumento sólido y suena más a deseo de estar a la moda que a razonamiento sensato. Es infinitamente más rápido, hablando de tiempos de desarrollo, migrar Access a .NET que a plataformas totalmente distintas como pueden ser PHP, Python, Smalltalk... En este punto hay que plantearse otra serie de cuestiones para dilucidar si es práctico cambiar por completo de tecnología. Por ejemplo, ¿cómo se financiarán los costes de la migración? ¿Existe algún compromiso que marque los tiempos de desarrollo? ¿La empresa dispone de personal cualificado en las tecnologías alternativas? En caso contrario, ¿es rentable formarlos adecuadamente?

Una vez resueltas todas estas dudas, se está en disposición de entrar en disquisiciones técnicas. Los techies (o geeks, todavía no me aclaro) tendemos a analizar todas las cuestiones bajo un enfoque técnico y eminentemente práctico. Pero lo práctico, en relación con muchas decisiones profesionales, sería dejar la técnica en casa, al menos por un rato. La web es un mundo fascinante y lleno de posibilidades, fuera del cual no puede sobrevivir ninguna empresa de servicios, y mucho menos una consultora TIC. Lo cual no significa, por mucho que a veces nos empeñemos en sacar a relucir las virtudes técnicas de la Web 2.0, que absolutamente todo tenga que pasar del papel o del escritorio del ordenador a un navegador. Volviendo al principio, creo que no puedo ofrecer un consejo más sensato.