6.5 KiB
Normalización de la persistencia
Se mantiene Sequelize 6 y MariaDB. El criterio del proyecto es almacenar datos de negocio en columnas y relaciones, sin documentos JSON. Los objetos values del dominio y el JSON del contrato HTTP no implican columnas JSON.
Estado de la normalización
La normalización completa todavía está en curso. Esta revisión extiende el modelo relacional anterior de activos a recursos, puestos, asistencia y configuraciones de perfiles. No representa el cierre de la auditoría de toda la base.
| Ámbito | Persistencia actual |
|---|---|
| Compañías, personas, departamentos, sedes, usuarios y marcas | Columnas y relaciones existentes |
| Catálogo e inventario de activos | Definiciones, campos tipados, especificaciones y revisiones normalizados previamente |
| Catálogo e inventario de recursos | Definiciones, opciones, secciones, especificaciones congeladas, valores tipados e integración en columnas/tablas |
| Puestos de trabajo | Nombre, estado y referencias en columnas; activos exclusivos/compartidos por puesto y revisión en tablas |
| Asistencia técnica de activos | Destino, VPN, preferencia, estado y notas en columnas actuales e históricas |
| Perfiles de usuario | Nombre, estado, notas y referencias en columnas actuales e históricas |
| Teletrabajo | Estado, periodo, notas y persona en columnas actuales e históricas |
| Aplicaciones, certificados, impresoras y carpetas del perfil | Valores escalares y referencias en columnas actuales e históricas |
| Cuentas y accesos | Pendiente: catálogo discriminado, asignaciones, permisos, grupos y necesidades |
| Correo | Pendiente: proyecciones de buzones, usos y configuraciones, incluido su formato histórico anterior |
| Accesos remotos | Pendiente |
| Procesos y plantillas de procesos | Pendiente: pasos y revisiones |
| Tickets e intervenciones | Pendiente: afectados, pasos, procedimiento y plantillas |
| Sesiones HTTP | Pendiente de evaluar el contrato del almacén de sesiones existente; no se introduce una excepción nueva para JSON |
Las columnas data de fotos y logotipos son datos binarios; no son documentos JSON de negocio.
Recursos
Las tablas existentes resource_definitions, resource_template_fields, resources y resource_revisions mantienen sus identidades. Se añaden:
resource_field_choices: opciones ordenadas de cada campo.resource_template_sections: secciones ordenadas, identificadas por(templateId, id); copiar una plantilla puede conservar los identificadores internos de sus secciones.resource_specification_sections,resource_specification_fieldsyresource_specification_field_choices: definición congelada al crear el recurso.resource_characteristicsyresource_revision_characteristics: valores actuales e históricos con columnas independientes de texto, número, booleano y fecha.
La ausencia de una característica se representa mediante ausencia de fila. Una cadena vacía, 0 y false siguen siendo valores y se conservan. Las fechas se leen como fechas ISO. La especificación congelada no se reemplaza por el estado actual del catálogo.
Los vínculos de integración con buzones y accesos se conservan en columnas con claves foráneas. Eliminar una referencia externa no debe eliminar en cascada el recurso ni sus revisiones. Las proyecciones de compatibilidad de correo/accesos siguen existiendo hasta normalizar sus consumidores.
Puestos, perfiles y configuraciones
workstation_members conserva la composición actual del puesto, con tipo exclusive o shared y posición. workstation_revision_members conserva la composición de cada revisión. workstation_assets sigue siendo la proyección técnica que protege referencias históricas y reserva activos exclusivos de puestos vigentes; no es otra asignación de negocio.
Los perfiles y configuraciones mantienen sus reglas de unicidad, transiciones y cierre. El cambio de persistencia no modifica rutas, formularios, DTO, contadores, permisos, identidad ni comportamiento funcional. Las referencias de las revisiones se conservan mediante claves foráneas.
Migraciones
Las migraciones se ejecutan explícitamente al inicializar los módulos; no se utiliza sync({ alter: true }).
- Se añaden columnas y tablas de destino sin borrar el origen.
- Se valida el documento anterior mediante el esquema de dominio, incluidas las referencias ya persistidas.
- La transferencia de valores se realiza en una transacción.
- Se reconstruye el destino y se compara con el origen antes de retirar las columnas antiguas.
- Se eliminan las columnas JSON transferidas y se refuerzan las restricciones.
El DDL de MariaDB no es transaccional. Una interrupción puede dejar columnas de preparación, pero el origen se conserva hasta verificar la transferencia. La migración de recursos admite también el corte en el que las revisiones ya se transfirieron y el recurso aún conserva sus columnas de origen. Repetir las migraciones no añade revisiones ni duplica datos.
Las pruebas de integración utilizan exclusivamente metis_desk_test. Comprueban origen inválido, conservación de UUID/historial/orden/valores, referencias incompatibles, idempotencia, arranque vacío y mantenimiento del comportamiento HTTP. Las fixtures SQL que antes escribían JSON se adaptan a las tablas nuevas.
Continuación pendiente
Antes de dar por terminada la normalización hay que implementar y verificar las filas pendientes del inventario, adaptar sus lectores de dashboard/procesos y proyecciones de compatibilidad, y repetir una auditoría del esquema real y del código de persistencia. No basta con cambiar una columna JSON a LONGTEXT ni con renombrar los documentos serializados.
Verificación de esta revisión
- Suite completa: 277 pruebas superadas; espaciado: 3 pruebas superadas.
- Typecheck de servidor, activos, compañías y recursos: correcto.
- Build: correcto; mantiene el aviso de tamaño de bundles del frontend.
- Biome y ESLint sobre los ficheros modificados en esta revisión: correctos.
- Arranque y migraciones sobre una base de pruebas vacía: correctos.
- Inicialización de desarrollo: comprobada después de guardar una copia SQL externa al repositorio en
/home/david/backups/metis-desk/.
El typecheck global sigue encontrando el problema anterior de locale en packages/shadcn-ui/src/components/calendar.tsx. El lint/check global conserva errores de otros ficheros (principalmente código de fotos y formato pendiente). No se modifica código vendor ni cambios de interfaz ajenos a esta normalización.