Fwd: Versionar Base de datos

[Gabriel Osorio]

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".

Entrada del Blog: Reflexiones sobre Software

[Carlos Peix]

Hola Gabriel,

En tu excelente descripción de la situacion, creo que utilizaste dos conceptos en forma intercalada y prefiero distingirlos para mi respuesta: entiendo que una cosa es versionar datos y otra es versionar bases de datos.

El versionado de datos lo he visto en algunos casos, como sugeriste, con una columna adicional indicando con que version de la aplicacion se grabo ese dato (un producto, por ejemplo). Prefiero dejar fuera de mi respuesta esta situacion pues nunca la he experimentado y me parece compleja por demás. Habrá circunstancias en las cuales se utilice, supongo.

Luego, el problema de que la información en la base de datos resulte inconsistente con la nueva version de la aplicacion, creo que debe resolverse como parte del mismo proceso de actualización. Por ejemplo, la nueva version de la aplicación requiere de un dato adicional que debe tener un valor determinado.

Por supuesto, toda la información ya presente en la base de datos no tendrá ese dato. Entonces, lo que suelo hacer es colocar un valor default comoparte del proceso de actualizacion (agregando una sentencia UPDATE...). Otra opcion que se me ocurre pero que no he usado nunca es colocar un valor "magico" en esa columna que oblige a la aplicacion a un comportamiento especial, obligando al usuario a seleccionar el valor correcto en la primera interacción como ese dato.

Tal como mencionaste, uso la técnica por la cual toda version de la aplicacion requiere una determinada version de la base de datos y no operará sin esa actualización. Hace ya años desarrolle un utilitario parecido a los actuales migration tools que son capaces de actualizar la base de datos automaticamente (incluyendo UPDATES, INSERTS, etc) antes de arrancar la aplicacion.

Tambien son capaces del downgrade, en caso de que tenga que revertir a la version anterior de la aplicacion.

Por supuesto, estas herramientas funcionan muy bien en los entornos de CI siendo, en mi opinion, imprescindibles en los mismos.

Un saludo!

----------------------------------

Carlos Peix

--

---
Has recibido este mensaje porque estás suscrito al grupo "agiles-colombia" de Grupos de Google.
Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a agiles-colomb...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/agiles-colombia .
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Alejandro Miralles]

Coincido con Carlos en separar lo que sería el versionado de los datos, de lo que sería versionar la base de datos en sí.

Para el primer caso, he visto en alguna instalación que utilizan una especie de hash que permite rastrear el dato, donde se creó, contra que esquema, etc…. Jamás lo utilice.

El tema de versionar la base de datos en sí, es un como más común, y si utilizas EF o Rails, ya tenés toda la infraestructura necesaria para poder ir hacia adelante o hacia atrás con las distintas versiones de la base/app. En este último caso, como el código para moverte entre versiones es parte del código fuente, ya está en tu SVN, GIT o lo que sea, y se puede versionar de la misma forma que versionas tu aplicación.

 

Saludos, Ale Miralles

http://amiralles.net

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un mensaje a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano .

[Miguel Angel Jimenez Perez]

Para la parte de versionado del schema(estructura) de la base de datos yo he utilizado fluent migrator y migrator-dot-net, siendo el 1ro el que mas he usado y se me hace mas sencillo de utilizar, y te permite hacer lo que haces en rails, hacer un migration up, un migration down y todas las operaciones para ir teniendo versiones de la DB, lo malo con esto, es que cada cambio que hagas tienes que ir definiendo el objeto para hacer los cambios de la version. 

En el caso de Nhibernate puedes hacer un schema update al momento de iniciar la sesion, y automaticamente verifica que el schema sea igual a la version de tu codigo y hace el upgrade, lo que si no hace, es downgrade. 

Lo otro que comentas de versionamiento de dato, pos creo que si tendrias que desarrollar algo para que lo puedas hacer manualmente, como mencionan otros compañeros, tener un campo que lleve la version del schema seria la unica forma de identificar esos datos contra que version de la db se guardaron.

Saludos.

[Juan María Hernández]

Hola,

Sobre el tema del versionado de datos, es interesante es el enfoque de algunas bases de datos como Datomic (http://www.datomic.com) o EventStore (http://geteventstore.com/), en las cuales la información nunca se modifica (y por tanto nunca se pierde). Eso te permite consultar siempre el estado de la información en cualquier momento de su historia.

En el caso de EventStore está más enfocada a (como era de suponer por el nombre) almacenar streams de eventos al estilo del event sourcing que se usa a veces en CQRS, pero Datomic es más "de propósito general", siempre teniendo en cuenta que sigue siendo una base de datos bastante exótica :-)

Saludos,

Juanma.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un mensaje a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano .
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Blog: http://blog.koalite.com

[Gabriel Osorio]

Hola,

Gracias Carlos, Alejandro, Miguel Angel, Jorge y Juan María. Llevo pensando y digiriendo sus aclaraciones, aportes, explicaciones y sugerencias. Disculpen si insisto con el versionado de datos y de su utilidad.

En resumen tenemos (si alteré algo corregir):

1. Base de datos (estructura) mutable y datos mutables.
   
1. Estrategia de conversión de datos.
1. Datos inconsistentes.
2. Manejo de excepciones por código.
2. Actualización de estructura.
1. Shutdown / Reinicio.
2. Control de versiones de Scripts / Store procedures.
1. Upgrade / Downgrade.
1. Manual o Heurístico.
2. Automático: Rails, Liquibase.
2. Base de datos (estructura) mutable y datos inmutables.
   
1. Versionado de datos. Datomic.
1. Histórico enlazado.
2. Streams de eventos. EventStore.
1. Histórico timeline.

Por ahora el alcance de esta reflexión estará enfocado a las primeras, las SQL. Las noSql o funcionales están por digerir.

Paso a hacer una breve exposición de la utilidad de ese campo entero. Para ello supongamos que todo es ideal y automático y no existe "select *".

Una tabla guarda la versión del sofware generada automáticamente. Y el id se guarda en las tablas.

id   version

1     0.1.0

2     0.3.2

...

957   1.1.7

Supongamos un select. Puede funcionar casi para cualquier versión del software si tiene un valor bajo de versión o ninguno:

select nombre, apellido from users where version > 30

Una directiva puede exigir que tanto Insert como Update y Delete se hagan con la última versión. Otra forma sería usar Last para version, algo como:

if version = Last then update ... etc.

Así, cada Store Procedure / Script tendría un número de versión mínimo con el que opera.

La ventaja es que la aplicación desactualizada sigue funcionando pero no puede operar sino con datos viejos y no puede modificar la base de datos o introducir inconsistencias (viviría congelada.)

Otra ventaja (supongo) es que el control de excepciones dentro del software se hace más simple.

La gran ventaja está por el lado de la trazabilidad.

Todo el tiempo los usuarios informan sobre errores o inconsistencias, si se les pregunta, la respuesta es que el software siempre ha funcionado bien y de pronto ya no.

    Si se puede conocer qué versión de software produjo los datos, se puede saber desde hace cuanto se produce el error, cargar la versión antigua y hasta confirmar y si era notorio en ese momento.

   Otra ganancia es poder aislar lotes. Si el daño existe en un solo lote, se puede hacer la traza sobre esos datos únicamente. Tanto que se pueden exportar productos completos a un ambiente controlado sin tener que copiar toda la base de datos.

   Igualmente, se pueden aplicar correcciones por lotes si se identifican errores diferentes y ortogonales entre si. Cosa que permitiría liberar más rápido los parches y hacerlos más pequeños.

   Incluso de pueden "jubilar" registros completos por edad, desuso o anacronismo: Borrar sin miedo! Cargar backups sin miedo!

Para terminar. La idea original era hacer que cada rutina colaborara en la construcción de ese número de seguimiento de manera que estuviera codificada la ruta, rutina por rutina, del software que creó el dato. Obviamente algo así es absurdo porque sería como codificar los engranajes de la máquina.

Gracias por leer esto, aspiro a que tengan más respuestas y sugerencias.

Gabriel

[Carlos Peix]

Hola Gabriel,

Debo decir que no tengo esperiencia con lo que estas sugiriendo.

Lo que si puedo decir es que yo no me meteria en el tipo de problemas que mencionas a menos que no quede otra alternativa, es decir, manejar distintas versiones de los datos en la misma tabla.

En otras palabras, que necesidad de tu negocio te impide actualizar la version de los datos almacenados a la ultima version compatible con la aplicacion?

A partir de esa necesidad probablemente podamos sugerirte otras maneras de manejar el asunto que no sea dejandolo en manos de la capa de persistencia.

----------------------------------
Carlos Peix

--

---
Has recibido este mensaje porque estás suscrito al grupo "agiles-colombia" de Grupos de Google.
Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a agiles-colomb...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/agiles-colombia .

[Gabriel Osorio]

Carlos, Gracias por seguirme la corriente. Aspiro a ser más claro y conciso que en el correo anterior.

Parto de la idea de que una base de datos es legacy apenas entra en funcionamiento en producción.

Mi idea está en pañales y creo está relacionada con las áreas de QA y operaciones. Donde las rutinas, el tiempo de evaluación y despliegue están sometidos a procedimientos lentos y burocráticos.

En mi experiencia he sido "el nuevo" con bases de datos muy grandes en dos oportunidades. Muchas tablas, muchos registros, muchos parches y muchos campos "A", "O", "T", "N" (como contabas), muchas líneas de código y muchas cosas sin nombre con extensión .exe.

La mayor dificultad fue poder extraer productos completos para evaluar daños, verificar mejoras o probar módulos nuevos; pues no existen registros "típicos" cuando las reglas de negocio son complejas.

Por ejemplo una financiera intermediaria de compras a nivel mundial: Tendrá módulos para importaciones, exportaciones, tesorería, contabilidad, impuestos, web proveedores, web clientes, web socios, interfase con otras DBs, api propia, otras apis, crédito, cartera, área operativa, área comercial, call center... etc... etc... etc. Todos pegando contra la misma DB por años de años.

Mover una base de datos como esta a desarrollo es imposible. Por lo tanto, "probar" puede costar mucho y requerir gran cantidad de esfuerzo porque solo se tienen los esquemas y algunos datos incompletos elegidos "al azar". He ahí la razón de los retrasos para llegar a producción; la organización tiene plena conciencia de esas limitaciones.

Mi necesidad radica en incluir la posibilidad de probar ágilmente (automáticamente?) en instancias posteriores al desarrollo; como el área de operaciones. Dejar para el futuro el embrión de una especie de TDD (en caliente?) para bases de datos que no modifique los datos, algo así, no es tan claro.

Ahora mismo estoy desarrollando usando una NoSQL, tengo un esquema muy simple (nada como el escenario propuesto) y a veces prefiero borrar todo y recrear el esquema a tener que lidiar con datos de versiones viejas. Al subir una nueva versión no es raro recibir un mensaje que dice: "el link tal dejó de funcionar" y el trabajo de testing del cliente se pierde (nada terrible.) La idea es crecer exponencialmente una vez llegue a producción, en ese momento esos lujos se acabarán.

Ya antes me habías advertido que existe un método de "grabadora de comandos". Se aplica el parche, se devuelve la cinta y se pone a reproducir. Luego se verifica que los datos introducidos por esos comandos sean correctos. De nuevo el problema radica en que no se tiene toda la base de datos en desarrollo y puede llegar a ser costoso tenerla en QA, dejando inconsistente la DB con la que se prueba (con cuenta de cobro para el futuro cercano.)

Devolver la historia con datomic o eventStore parece razonable, pero ¿Cuánto?

[Carlos Peix]

Gracias por la explicacion Gabriel.

Me siento cada vez con menos contexto para opinar pero, de instinto nomas, creo que toda la energía que deseas aplicar en estas ideas, sería mas util en un proyecto de reemplazo paulatino de esa estructura de datos.

Pero, repito, creo que no tengo contexto.

----------------------------------
Carlos Peix

[Gabriel Osorio]

Mil gracias Carlos.

[Gabriel Osorio]

Gracias David. Muy buenos artículos. Una característica importante de versionar la base de datos, según el autor, es:

Is a customer reporting a bug on build 3.1.5.6723? Pull the source code tagged or labeled with that version number and run the baseline, then all schema change scripts included in the tag. You now have the same database and have a much better chance to recreate the bug. 

Ahora, suponiendo que eso existe y funciona perfectamente. El autor resume en dos enunciados otro problema:

Condición 1:

A second goal is to have the ability to recreate a database at any point in time. 

Condición 2:

Of course, changes are not just about schema changes. You also have to write the code to migrate data. For instance, if for some reason we moved the ShoeSize column from the Customers table to the CustomerDetails table, the update script will also need to move and preserve the data. Data manipulation is often the trickiest part of change scripts and where they need the most testing.

Pensemos:

Es posible luego de ocurrir la segunda condición, cumplir la primera usando el método de versionado de base de datos descrito y con los materiales fabricados disponibles?

Para lograrlo tendríamos que hacer un script hacia adelante (evolutivo), y otro script hacia atrás (involutivo). Cosa que nadie hace porque no tiene sentido.

Más abajo este comentario:

... writing a change script to rename an existing column, change it from varchar to int...

Y responde:

The change scripts many tools build often don't work for me because of the size of the databases I work with. Some of these scripts will run for hours and hours. Most of the change scripts are hand written with loving care. It's great to have a few developers around who are good with SQL – I know not every team has this luxury, and I honestly don't have a good answer to that problem.

Un símil entre las divisiones de tiempo y tamaño de los elementos de la base de datos puede ser útil para pensar sobre la necesidad de "recrear el bug". Usando como abstracción particiones horizontales de la base de datos:

Esquema DB --------------------> Siglos. 

Registros DB ------------------> segundos.

Versionar DB ------------------> Lustros.

Registrar origen de los datos -> Años.

Versionar datos DB ------------> Meses.

Faltan estrategias para relacionar el símil con semanas, días y horas.

El 13 de marzo de 2014, 23:29, David Roncancio <david.r...@gmail.com> escribió:

Hace mucho lei esta serie de posts que me parecio muy util en este tema 

http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx 

http://odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx

http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-change-scripts.aspx

http://odetocode.com/blogs/scott/archive/2008/02/03/versioning-databases-branching-and-merging.aspx

Puedes arrancar por el ultimo que tienen un indice a los anteriores o leerlos en orden (cronologico)

ademas va muy de la mano con lo que propones

cordialmente, 

David Roncancio
(+57) 3014311354

[Gabriel Osorio]

Pensando en recrear lo mejor posible las condiciones en las que un bug se materializa, la analogía con el tiempo se puede explicar como:

Un registro       == Un punto de historia de usuario

Una base de datos == Epica

Voy a darle una ojeada a South. Una objeción que había hecho previamente a esa estrategia es que el software viejo deja de funcionar.

Seguro alguien ya lo pensó y lo describió, una lástima no poder encontrarlo.

Gracias David.

El 14 de marzo de 2014, 17:15, David Roncancio <david.r...@gmail.com> escribió:

Hay librerias que hacen esta labor mucho mas facil, auto generar los scripts basados en cambios con el ORM, generando los scripts para ir hacia adelante y hacia atras (ex. http://south.readthedocs.org/en/latest/), no entiendo la ultima parte de Tiempo

cordialmente, 

David Roncancio
(+57) 3014311354

[Gabriel Osorio]

Disculpen que siga, algo en la discusión me llevo a encontrar que estábamos hablando de "versionado de tablas".

El uso principal son las transacciones (datomic, couchdb, eventstore) con concurrencia multiversión (MVCC) para evitar bloqueos basados en candados. Apropiado para aplicaciones con muchos usuarios (big data) o transacciones largas (ejemplo hibernate).

También encontré el entero del que hablaba, en la aplicación específica se llama "linaje". Va acompañado de tablas delta y se usa para un control de versiones de datos sobre un GIS.

http://help.arcgis.com/es/arcgisdesktop/10.0/help/index.html#//00270000000r000000

Otra lectura habla de DataWarehouse (DW) y Business Inteligence (BI). El tipo de versionado se hace con campos de fecha (desde, hasta) y sirve para OLAP y Reportes entre otros.

http://www.guillesql.es/Articulos/Versionado_Fecha_Desde_Fecha_Hasta_Versiones_Consultas_SQL.aspx

Ahí al tal campo entero se llama clave subrogada cuando es artificial, y cuando no, se usa un campo compuesto llamado secuencia de cambio. 

Para hacer una analogía con la situación planteada y los nuevos hallazgos:

1. Recrear un bug es un proceso similar a crear un cubo OLAP en caliente donde la DB se ve como un DW. Los pescadores de bugs más eficientes serán quienes usen técnicas de data mining.
2. Mantener compatibilidad de versiones y trazabilidad del producto estaría planteado como BI de software. Se puede extraer información de la empresa de software, sus fortalezas y debilidades (no las del cliente, el dueño de los datos.)
3. Es una forma de introducir control de versiones para los datos (linajes), así cada versión de software puede usar su propia rama.

El 15 de marzo de 2014, 10:28, Alvaro Triana <alvaro...@brainz.co> escribió:

Estan muy interesantes todos los aportes, los leere con calma para dar alguna opinión lógica.

[Carlos Admirador]

Sería bueno comentaras alguna conclusión final si se llega a término.

La presentación #AgileOpenBogotá de Adrián Moya está disponible?

En otro  hilo, sería interesante abrir discusión de versionado de servicios web :-D

Saludos.
Carlos.

[Gabriel Osorio]

Hola Carlos

Efectivamente hay un avance, al menos ya tiene nombre: teselado.

http://es.wikipedia.org/wiki/Teselado

El teselado actual de todas las bases de datos es cuadrado, pero hay otros dos tipos de teselado regular posibles: con triángulos equiláteros o con hexágonos. Además hay ocho teselados semiregulares y gran variedad de teselados irregulares. Tal vez los más famosos son los hiperbólicos fruto del trabajo de M.C. Escher:

http://www.mcescher.com/gallery/mathematical/circle-limit-iv/

Otro artículo sobre lo mismo:

http://es.wikipedia.org/wiki/Teselado_regular

En los SIG es una función importante, por eso apareció durante la investigación.

Ahora a digerir todo esto.

Saludos

Gabriel

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.

[María NET Developer - Mírame a los ojos]

Estimado Gabriel, algunas conclusiones más?

Saludos, estimados.

[Gabriel Osorio]

Si, hay unas cuantas conclusiones adicionales.

La inclusión de campos JSON en las DBs como MySQL permite agregar metadata, de manera que el versionado de datos es más flexible.

Supongamos una empresa de apuestas donde se vende mediante HTML, android, IOS, call center (desktop app) y servicios REST. Supongamos que usan una sola base de datos. Si se descubre un fraude, una anomalía estadística o algo similar, sería conveniente poder determinar, mediante esa metadata, el canal defectuoso.

Si además la metadata incluyera información de la estructura interna de la aplicación, se podrían encontrar las fallas más deprisa, además de poder agrupar los datos de prueba para hacer revisiones y/o correcciones.

Teniendo en cuenta lo anterior, existe la alternativa de hacer análisis probabilísticos para identificar los módulos o clases que exhiben baja cohesión y/o alto acoplamiento (más probable que fallen o que un fallo tenga alto impacto) de manera que los datos generados por estos bloques (metadata que incluye un hash de versión) permitan la trazabilidad hacia atrás deseada.

Otros dos ejemplos del porqué puede ser necesaria esta solución son: 1)cambios en la ley (por ejemplo iva del 10% al 18%) y 2) desarrolladores nóveles. (Recordemos que la motivación viene de bases de datos de prueba que contienen información desactualizada y/o incompleta; o de aplicaciones en constante cambio tales como juegos online.)

El jue., 5 jul. 2018 a las 15:39, María NET Developer - Mírame a los ojos (<mmiramealosoj...@gmail.com>) escribió:

Estimado Gabriel, algunas conclusiones más?

Saludos, estimados.

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/altnet-hispano.

[Carlos Admirador]

Algún caso práctico o getting started - step by step ? O checklist ?

Sin duda hay muchas referencias:

https://enterprisecraftsmanship.com/2015/08/10/database-versioning-best-practices/

https://app.pluralsight.com/library/courses/database-delivery-best-practices/table-of-contents

https://www.codeproject.com/Articles/712449/SQL-Server-Database-Versioning

http://blog.koalite.com/2018/05/auditoria-quien-ha-hecho-que/

https://rob.conery.io/2015/02/20/its-time-to-get-over-that-stored-procedure-aversion-you-have/

https://wateroxconsulting.com/archives/versioning-in-your-sql-database/

https://www.infoq.com/articles/db-versioning-scripts

2 tablas para Versiones de la BD, y de Histórico:

DbVersion definition

Column name	Column type
Version	Nvarchar(50)	Not null
UpdatedBy	Nvarchar(50)	Not null
UpdatedOn	DateTime	Not null
Reason	Nvarchar(1000)	Not null

DbHistory definition

Column name	Column type
Filename	Nvarchar(50)	Not null
Content	Nvarchar(max)	Not null
RunOn	DateTime	Not null

[Gabriel Osorio]

Creo que tengo una respuesta. Veamos la idea inicial:

Suponga el funcionamiento del software como una fábrica de televisores donde cada rutina es una máquina ensambladora de componentes. 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. O si es un defecto del componente, se desecha todo el lote y se avisa al fabricante. 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.

El caso asimila el funcionamiento del software con un proceso de agregación. Sin embargo, hay al menos otro tipo de proceso manufacturado:

Un chasis, armazón o estructura metálica puede ser obtenida a partir de una lámina de metal mediante doblado, troquelado y/o cortado.

En este caso, hablamos de un proceso de transformación en el que se obtiene un producto al final.

Por lo tanto, la pretensión de obtener trazabilidad total, rutina a rutina, es un sinsentido, pues los procesos de transformación (fuente de los errores más difíciles de hallar y corregir) generarían una enorme cantidad de metadata.

Un caso puede ser un MMORPG en el que después de un año cada jugador tiene una configuración diferente y única y donde un proceso puede durar meses. Un error que afecta un aspecto del juego actual puede haber sido originado por una versión antigua de una rutina puesto que el jugador no ha actualizado a la última versión, como en el caso de los celulares. Incluso puede que hacer la actualización no corrija el problema.

En el caso de tener una trazabilidad excesiva como la descrita al inicio, hallar la causa sería pan comido. Pero el precio sería prohibitivo.

Saludos