Json to Dom with jQuery

jQuery plugin to fill in DOM nodes with JSON. Simpler and more flexible than most templating / binding engines:
https://github.com/gescript/json-to-dom

Versionar Base de Datos y versionar los datos de la DB

En #AgileOpenBogotá (estuvo buenísimo!) mientras Adrián Moya nos contaba sobre los métodos y herramientas automatizadas para operaciones basadas en las técnicas ágiles tales como TDD, BDD, ATDD, Integración Continua...etc. Surgió una duda sobre los problemas de versionado de la base de datos.

En el caso expuesto como problemático, la base de datos cambiaba con el tiempo, de tal manera que en poco tiempo los datos eran incompatibles entre versiones. El escenario se hacía más complejo al tener, obligatoriamente, que mantener diferentes versiones de la base de datos de manera concurrente.

El caso puntual: cuando es el cliente quién decide (o no) actualizar. Por ejemplo: un juego en línea descargado desde una tienda para dispositivos móviles, tabletas o pc's.

O un caso adicional: cuando la ley exige la integridad de esos datos (como en contabilidad) pero esa misma ley es cambiante en cuanto a métodos, fórmulas o restricciones; como por ejemplo una reforma tributaria. O simplemente la base de datos es muy grande.

Para hacerse una imagen del problema, piense en el software como una fábrica de televisores donde cada rutina es una máquina ensambladora. Cuando un televisor recién ensamblado presenta un defecto se puede encontrar la máquina que está fallando para ser reparada o reemplazada (trazabilidad interna) y el televisor se repara o desecha. Si el televisor está fuera de la fábrica; usando trazabilidad normal o inversa se obtiene el mismo resultado, depende de quién haya encontrado el defecto, ya sea el fabricante o el cliente.

Este ejemplo surge de las vacas locas donde la carne infectada debía ser retirada del comercio y la información de trazabilidad permitía encontrar el rancho de donde provenía.

Versionamos el software según sus partes o remiendos, pero no versionamos los datos.

Ese fenómeno puede bautizarse como las vacas locas del sofware. Tenemos software que consume productos de software. Pensar que en algún momento los datos se integrarán y las máquinas enloquecerán no es ficción, ocurre en las bolsas de valores a velocidades inimaginables y de forma compleja, dejando de paso pérdidas extraordinarias entre otros.

¿Qué hacer?

La explicación de Adrián (según entendí) solucionaba el problema registrando tanto la versión del software como la de la base de datos y migrando los datos al nuevo formato.

Pero este no es el caso. ¿Qué hacer si no es posible migrar los datos? ¿Hay una opción simple, barata, fácil de implementar y mantener?

Primera solución (ingenua y causa overhead.)

Agregar una columna a cada tabla donde se registra la versión del software que la elaboró (tal como se marca el televisor e inviolable como una llave primaria.) Será un valor diferente a la versión de la base de datos (un entero basta.)

Con esto al menos el software podría reaccionar ante registros desactualizados.

Otra solución (engorrosa y absurda.)

Crear una base de datos nueva cada vez que hay un cambio. Pero, un select o un join serían trabajo arduo, incluso imposible.

¿Qué otras soluciones hay?

En verdad hay muy poca información sobre trazabilidad normal e inversa en este campo (o no la supe hallar.)

Mientras tanto, el aviso "Hay una nueva versión del software, descárguela o asuma las consecuencias" es una opción "recomendable".