Mucha información, como por ejemplo, aquella generada por los análisis de los laboratorios, pierden flexibilidad cuando dependen del típico esquema de los sistemas de bases de datos. Esto ocurre básicamente porque son demasiados los campos de un solo análisis, y aunque bajo esos esquemas esté permitido una gran cantidad de columnas, siempre finita, las labores de administración son siempre incómodas por la constante necesidad de nuevos campos. Esta es la razón por la cual l@s químic@s prefieren almacenar el resultado de sus análisis en hojas electrónicas, que, con un poco más de agilidad son subidos a la web utilizando Google Apps
Yo siempre sostengo que las hojas electrónicas salvan vidas, y no me vayan a decir que nó: los expertos son realmente expertos cuando manejan bien hoja electrónica, desde los tiempos de lotus 123 a inicios de los 80, pasando por Quattro, hasta que Excel se impuso desde media mitad de los 90.
Hay dos formas de amenazar a un expert@: la primera es por decreto presidencial (realmente no existe aún) con el que se exija la utilización de un determinado producto como Calc de OpenOffice. La segunda es que por necesidad de integración de datos se trate de implantar un sistema con pantallas super sexys pero poco flexibles como aquellos en Visual Basic de finales del siglo pasado. Es mejor no estorbar el trabajo de expert@s, sean ell@s en el campo de la química o la contabilidad.
El problema de las hojas electrónicas es que su utilización, no implica integración de información, y eso es bien grave y limitante a la hora de analizar datos. Una salida es comenzar a odiar a todo aquel o aquella que generan información en hoja electrónica, y otra es comenzar a entenderlos. Personalmente recomiendo esta última opción, especialmente si no quiero comenzar a vender hamburguesas el próximo lunes.
El reto es integrar fuentes de datos almacenados en hojas electrónicas, y no hay mejor cosa que hacerlo mediante la construcción de aplicativos que extraigan esa información y las almacene en una base de datos. El problemas es que la información almacenada por lo general carece de esquema, toda vez que se utiliza la misma funcionalidad de la hoja electrónica para procesarla, y tal esquema por ser libre puede variar de un dpcuimento a otro. La solución está en saber extraer propiedades atómicas en formato par propiedad:valor, por ejemplo {“temperatura”:”14”}. La colección de las propiedades cuidadosamente seleccionadas, representan muy bien el documento y el pensamiento del experto. Mientras el esquema de extracción de dichas propiedades se debe mantener muy flexibles.
Las herramientas que permiten almacenar la información de esta manera se las califica como “libres de esquema” o bases de datos “NoSQL” (aunque MongoDB ofrece funcionalidad SQL), y me permití tratar de evaluar dos de ellas: CouchDB y MongoDB. La primera sufre de problemas de portabilidad en OpenSUSE 11.2 y nunca pude instalarlo ya que las “dependencias” entraron en crísis con la instalación de OpenOffice de mi laptop. Personalmente considero graves los problemas de portabilidad entre diferentes linux. En cambio MongoDB lo instalé sin problema alguno, y cuando lo descubrí, seguí su tutorial práctico y en línea en la sección “TRY IT OUT” del mismo portal, excelente experiencia !.
A mediado de agosto del 2010 la literatura de MongoDB es menor que para CouchDB, pero Manning, Apress, O'Reilly y Addison-Wesley ya anuncian publicaciones. El manual en línea, debería ser suficiente.
Quiero terminar clarificando lo siguiente: la transferencia de información desde las hojas electrónicas tiene su nivel de dificultad en el aplicativo que lee la información y lo sube a la base de datos, para el no programador... MongoDB se hace querer pero Java o cualquier otro lenguaje de programación es difícil de entender.
