# Persistencia relacional 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. ## Modelo de almacenamiento El modelo utiliza columnas y relaciones para activos, recursos, configuraciones, cuentas y accesos, correo, procesos, tickets, intervenciones y sesiones HTTP. Los contratos HTTP utilizan JSON como transporte; el almacenamiento es relacional. | Ámbito | Persistencia actual | | --- | --- | | Compañías, personas, departamentos, sedes, usuarios y marcas | Columnas y relaciones | | Catálogo e inventario de activos | Definiciones, campos tipados, especificaciones y revisiones en columnas y tablas | | 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 | Referencia al recurso de asistencia, 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 | Subtipos en tablas actuales e históricas; permisos de necesidades en asociaciones ordenadas | | Correo | Buzones, usos y configuraciones en columnas actuales e históricas | | Accesos remotos | Origen, destinos con claves foráneas independientes, VPN y estado en columnas actuales e históricas | | Procesos y plantillas de procesos | Columnas escalares y tablas de instrucciones/tareas actuales e históricas | | Tickets e intervenciones | Columnas actuales e históricas; afectados, pasos, procedimientos congelados y plantillas en tablas relacionadas | | Sesiones HTTP | Almacén Sequelize propio: autenticación, CSRF y opciones de cookie en columnas; sin documento serializado | Las columnas `data` de fotos y logotipos son datos binarios; no son documentos JSON de negocio. ## Recursos Las tablas principales son `resource_definitions`, `resource_template_fields`, `resources` y `resource_revisions`. Sus tablas dependientes son: - `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_fields` y `resource_specification_field_choices`: definición congelada al crear el recurso. - `resource_characteristics` y `resource_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 conservan las integraciones y sus identidades; sus lectores y escritores también utilizan columnas y tablas normalizadas. ## 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. Las referencias de las revisiones se conservan mediante claves foráneas. ## Tickets, intervenciones y plantillas Los registros tickets, ticket_revisions, interventions, intervention_revisions, intervention_templates e intervention_template_revisions almacenan sus atributos en columnas. Asunto, descripción, estados, prioridad, canal, modalidad, fechas, minutos, diagnóstico, trabajo realizado, resolución, nombre y estado de la plantilla tienen columnas tradicionales según la entidad. `plannedDate` es una fecha SQL; los instantes ISO conservan su representación exacta en columnas de texto para no perder precisión del historial. Las diez tablas dependientes son: | Información | Actual | Histórica | | --- | --- | --- | | Afectados de tickets | `ticket_targets` | `ticket_revision_targets` | | Afectados de intervenciones | `intervention_targets` | `intervention_revision_targets` | | Ejecución de pasos | `intervention_steps` | `intervention_revision_steps` | | Pasos de plantillas | `intervention_template_steps` | `intervention_template_revision_steps` | | Procedimiento congelado | `intervention_procedures` | Procedencia inmutable de la intervención | | Pasos originales del procedimiento | `intervention_procedure_steps` | Copia independiente del catálogo | Un afectado tiene exactamente una referencia: persona, puesto, activo o recurso, con clave foránea real para cada tipo. Las asociaciones se identifican por propietario y posición; los pasos mantienen su UUID y un orden único dentro de cada propietario. Las claves foráneas restringen eliminar destinos referenciados, mientras que las filas dependientes pertenecen a su ticket, revisión, plantilla o procedimiento y se eliminan en cascada con su propietario. El procedimiento conserva plantilla, revisión concreta, nombre, descripción, estado original y pasos. La base comprueba que la revisión pertenece a esa plantilla. No se sustituye esa copia por el catálogo vigente. Una intervención sencilla puede no tener procedimiento, pasos, técnico o ticket, según las reglas existentes. Los repositorios reconstruyen los mismos Value Objects y agregados. Se mantienen las rutas, DTO, UUID, autores, fechas, contadores, reintentos idempotentes, revisión esperada, conflictos concurrentes y reglas para cerrar o reabrir. Los lectores del dashboard consultan las columnas normalizadas tanto del estado actual como de las revisiones. ## Inicialización del esquema Los módulos preparan explícitamente sus tablas, índices y restricciones antes de exponer las rutas. Las columnas obligatorias se declaran al crear cada tabla; las tablas dependientes se crean de manera idempotente. No se utiliza sync({ alter: true }). La lectura reconstruye los Value Objects y agregados desde columnas y relaciones, valida sus referencias e historial y rechaza persistencia inconsistente. Los cambios se guardan mediante transacciones. Repetir la inicialización no añade revisiones ni modifica valores de negocio. Las pruebas de integración utilizan exclusivamente metis_desk_test y comprueban creación del esquema vacío, operaciones HTTP, restricciones, historial, concurrencia e idempotencia. ## Cuentas y accesos Se conservan las raíces access_workspaces, access_items y access_revisions, y las proyecciones access_references y access_person_references. La raíz identifica compañía/ámbito y tipo; las revisiones mantienen UUID, secuencia, autor e instante. Cada tipo tiene una tabla de valores y otra de valores históricos: | Tipo | Actual | Histórica | | --- | --- | --- | | Sistema | access_system_values | access_system_revision_values | | Tipo de recurso | access_resource_type_values | access_resource_type_revision_values | | Permiso | access_permission_values | access_permission_revision_values | | Plantilla de grupo | access_template_values | access_template_revision_values | | Entorno | access_environment_values | access_environment_revision_values | | Cuenta | access_account_values | access_account_revision_values | | Titular/usuario de cuenta | access_account_person_values | access_account_person_revision_values | | Grupo | access_group_values | access_group_revision_values | | Pertenencia a grupo | access_membership_values | access_membership_revision_values | | Proyección de recurso | access_resource_values | access_resource_revision_values | | Permiso concedido | access_grant_values | access_grant_revision_values | | Necesidad | access_need_values | access_need_revision_values | | Cobertura | access_coverage_values | access_coverage_revision_values | ownerId es clave primaria y foránea a la raíz o revisión correspondiente. Las referencias entre elementos y personas tienen claves foráneas. access_need_permissions y access_need_revision_permissions conservan permisos y orden; no permiten duplicar un permiso dentro de la misma necesidad. Las vistas access_current_values y access_historical_values unen columnas de los subtipos para lecturas comunes, sin generar JSON SQL. El catálogo global y los ámbitos de compañía mantienen sus reglas. Se conservan titularidad histórica, cuentas compartidas, caducidad opcional, grupos, permisos, coberturas, bloqueos de concurrencia y proyecciones de referencias. ## Correo y accesos remotos mailboxes, mailbox_uses, mail_configurations y sus revisiones almacenan dirección, tipo/contexto, cuenta vinculada, personas autorizadas, periodo, perfil, protocolo, estado y notas en columnas. snapshotKind identifica el alcance de cada configuración de correo: persona/cuenta/activo o perfil/buzón. Las restricciones SQL exigen las referencias apropiadas a cada variante. remote_connections y remote_connection_revisions mantienen persona, tipo de origen, activo corporativo cuando corresponde, sede/red, método, VPN, estado y notas. El destino se separa en targetAssetId y targetResourceId, con claves foráneas reales. Las restricciones SQL impiden destinos incompatibles, un origen personal con activo corporativo y acceso al propio equipo como destino. Los repositorios, lectores de dashboard/procesos y proyecciones de recursos reconstruyen los contratos de dominio. Una persona puede tener múltiples configuraciones y cada cambio conserva el historial. ## Procesos process_templates y process_template_revisions tienen columnas de nombre, tipo, estado y notas. Sus pasos ordenados se guardan en process_template_instructions y process_template_revision_instructions. person_processes y person_process_revisions tienen persona, plantilla, nombre congelado de plantilla, nombre del proceso, tipo, estado y notas. person_process_tasks y person_process_revision_tasks conservan UUID de tarea, orden, título, estado, notas y referencia de revisión (tipo, UUID, etiqueta y procedencia). La referencia de una tarea es información congelada para revisar una situación, no una asignación viva. No lleva FK al elemento revisado: debe conservarse aunque ese elemento se retire o elimine. Sí existen claves foráneas entre procesos, personas, plantillas, revisiones y sus tablas dependientes. Las instrucciones originales y tareas históricas no se reemplazan por una plantilla modificada. ## Sesiones http_sessions almacena sid, expiración, fechas de creación/actualización, usuario, versión de autenticación, token CSRF y opciones de cookie. SequelizeSessionStore implementa el contrato de express-session mediante columnas tradicionales. Se conservan duración original y expiración de la cookie, opciones booleanas, autenticación y protección CSRF. touch renueva la cookie sin sobrescribir autenticación o CSRF de otra petición. Las sesiones vencidas no se recuperan y se purgan al guardar sesiones; la expiración tiene índice. No se necesita temporizador de fondo. El almacén rechaza atributos de sesión desconocidos en lugar de descartarlos. ## Comprobaciones de persistencia La auditoría de information_schema en desarrollo no encuentra tipos JSON, restricciones JSON_VALID ni columnas values, specification, characteristics, procedure u otros documentos serializados. Las columnas instructions de intervenciones son texto de instrucciones de un paso; data en fotos/logotipos es binario. La persistencia no declara DataTypes.JSON ni interpreta documentos serializados. El uso de JSON en HTTP, traducciones y logs es independiente del almacenamiento de negocio.