He trabajado principalmente en el desarrollo de aplicaciones empresariales y la gestión de la configuración. Su pregunta es representativa de los desafíos en tal entorno; cuando actualiza, por ejemplo, Microsoft Word, no necesita cambiar todos los documentos de inmediato de doc a docx. Y los documentos incluso tienen una estructura más simple una base de datos de relación completa.
No es así para las aplicaciones comerciales; los usuarios omiten lanzamientos, realizan cambios no autorizados en el modelo de datos y el sistema debe seguir funcionando y proporcionando los números correctos...
Usamos para nuestras propias aplicaciones (la más grande es como 600 tablas) una herramienta CASE de desarrollo propio que incluye bifurcación/fusión, pero el enfoque también se puede hacer manualmente.
Modelo de datos de versiones
El modelo de datos se puede escribir de forma estructurada. Por ejemplo, como contenido de tabla (CSV que se cargará en una tabla con metadatos) o como código que detecta la versión en uso y agrega columnas y tablas cuando faltan, incluidas las migraciones no triviales.
Esto incluso permite que varios usuarios al mismo tiempo cambien el modelo de datos.
Cuando usa la detección automática (por ejemplo, usamos una llamada llamada "verify_column" en lugar de "add_column"), esto incluso permite una migración sin problemas, independientemente del número de versión desde el que el cliente esté iniciando la actualización. Dicho procedimiento analiza la tabla que se va a cambiar y emite el DDL correcto, como alter table t1 add col1 number not null cuando falta una columna o alter table t1 modify col1 not null cuando la columna ya estaba presente pero anulable.
Para Oracle y SQL Server, puedo proporcionarle algunos procedimientos de muestra. En MySQL codificaría esto usando un lenguaje del lado del cliente, preferiblemente independiente del sistema operativo para permitir que las instalaciones se ejecuten en Windows y Linux. Tal vez usar Apache Ant cuando tenga experiencia con eso.
Datos de versiones
Dividimos las mesas en cuatro categorías:
- R:datos referenciales; datos que el sitio de la aplicación debe proporcionar antes de que realmente use el sistema. Por ejemplo, códigos de cuenta del libro mayor general. Los datos de referencia rara vez cambian después de la puesta en marcha y no aumentan de tamaño continuamente. Los contenidos reflejan el modelo de negocio del sitio donde se utiliza la aplicación.
- T:datos de transacciones; datos que el sitio registra, cambia y elimina durante el uso de la aplicación. Por ejemplo, las entradas del libro mayor. Los datos de la transacción comienzan en 0 y crecen continuamente. Cuando la empresa duplica los ingresos, los datos de transacciones también se duplican.
- S:datos sembrados; datos NO mantenidos por el usuario en el sitio pero proporcionados y mantenidos por la parte desarrolladora. Esencialmente, este es un código convertido en datos. Por ejemplo, 'F' significa 'Mujer'. Los errores en los datos iniciales pueden generar errores del sistema.
- O:el resto (idealmente no se necesita, ya que son técnicas, pero algunos sistemas requieren una tabla temporal A o una tabla temporal B).
El contenido de las tablas de la categoría 'S' (datos iniciales) se coloca bajo el control de versiones. Normalmente los registramos como metadatos en nuestra herramienta de casos, luego los llamamos 'conjuntos de datos', pero también puede usar, por ejemplo, Microsoft Excel o incluso código.
Por ejemplo, en Excel tendría una lista de filas de datos iniciales. En la columna A, puede ingresar una función de Excel como =B..&"|"&C..& "|" & ... que concatena todo y lo hace adecuado para cargar con una herramienta de carga.
Por ejemplo, en el código, podría tener una llamada como:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel es un poco difícil de poner bajo el control de versiones, lo que permite que varios usuarios cambien los contenidos al mismo tiempo. El enfoque con código es muy simple.
Recuerde también agregar funciones para eliminar datos sembrados obsoletos. Por ejemplo, enumerando explícitamente los datos sembrados obsoletos o eliminando automáticamente todos los datos sembrados presentes en las tablas pero que no fueron modificados por la última instalación.
