¿Control de versiones usando tablas de bases de datos o herramienta de control de fonts?

Nuestra aplicación tiene una database MS Access 2010 (lo sé … Preferiría mucho SQL Server, pero ese es otro tema).

Dado que MS Access almacena sus datos en files binarys monolíticos misteriosos únicos en lugar de scripts, mi equipo está pensando en crear varias tablas adicionales correspondientes a diferentes versiones del software y mantener estas versiones dentro de una database maestra.

Sugiero simplemente colocar el file binary en la misma herramienta de control de fuente que el código fuente del software. Entonces, la gran mayoría del contenido de la database sería un duplicado de las otras versiones, pero al less pone la herramienta de control de versiones en control de la fuente del software y la database simultáneamente de forma sincronizada.

La aplicación utiliza files XML que se exportan desde la database (no se vincula directamente a la database).

¿Cuáles son los pros y los contras de estos dos enfoques?

Estoy familiarizado con los methods de control de versiones para SQL Server, pero MS Access parece engorroso de administrar para aplicaciones con muchas twigs.

Para abreviar: está presionando Acceso a algo para lo que no está destinado.

Tienes los commands SaveAsText y LoadFromText que pueden exportar e importar la mayoría de los objects como files de text discretos. Esto ha sido utilizado por Visual SourceSafe para crear algún tipo de control de fuente pero no funciona al 100% de manera confiable.

Además, puede importar y exportar objects "tal cual" a otra database (file) creando algún tipo de control de versión.

Una vez trabajé con un equipo de una corporación muy grande que tenía todos los resources imaginables de MS y, sin embargo, terminamos con un sistema simple de files zip con un nombre de file que incluía la date y la hora.

Teníamos un file maestro accedido como una copy en una carpeta local, luego hicimos lo que se nos asignó, y copymos el file dejando una nota sobre qué objects fueron alterados. Una persona tenía la tarea de recolectar los objects alterados y "rebuild" un nuevo maestro. Un mínimo de uno por día, pero a menudo también creamos uno en el almuerzo.

Funcionó mejor de lo que imaginaba, porque normalmente operamos en diferentes rincones, uno con algunos informes, uno con otros informes, uno con algunos formularios y uno (normalmente yo) con algunos modules de código. Por supuesto, ocurrieron errores, pero como teníamos los files zip, siempre era rápido y seguro sacar una copy vieja de un object en caso de duda.