Entrada 4: Mas correciones al MF

 # Bitácora de Sesión

Fecha: 01/06/2026

Inicio: [19:00] | Fin: [22:00] || Total: [3 horas]

Presente: Matías Benavides Sandoval

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

¿QUÉ HICIMOS HOY?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • Se realizó una revisión profunda del modelo físico de la base de datos y se documentaron las inconsistencias más importantes.
  • Se corrigieron problemas estructurales del esquema SQL base para acercarlo a la especificación del proyecto.
  • Se alineó el backend con el esquema corregido, especialmente la conexión a la base de datos y los nombres de columnas usados por los controladores.
  • Se recreó la base de datos desde cero a partir del script actualizado y se validó que el despliegue quedara consistente.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PROBLEMAS DETECTADOS Y CÓMO SE RESOLVIERON

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  1. Problema: llaves primarias sin IDENTITY en tablas operativas.
  • Causa: varias tablas que representan entidades transaccionales dependían de capturas manuales de ID.
  • Solución: se ajustó el script Tablas.sql para que las tablas no catálogicas usen IDENTITY donde corresponde.
  1. Problema: tipos de datos incorrectos para horarios.
  • Causa: TipoJornada.HoraInicio y HoraFin no estaban modeladas como hora pura.
  • Solución: se cambiaron a tipo time para evitar ambigüedades de fecha.
  1. Problema: nombres de columnas y referencias inconsistentes.
  • Causa: el backend esperaba nombres distintos a los declarados en el esquema, especialmente en Usuario y en tablas de bitácora.
  • Solución: se ajustaron las referencias del backend para coincidir con el modelo real y se corrigieron nombres mal definidos en SQL.
  1. Problema: dependencia circular entre tablas relacionadas con deducciones y planillas.
  • Causa: la relación entre DeduccionMensual y PlanillaMensual estaba planteada de forma que complicaba la creación limpia del esquema.
  • Solución: se reordenó la referencia para romper la circularidad y permitir recrear la base desde cero sin conflicto.
  1. Problema: falla inicial al compilar el proyecto TypeScript.
  • Causa: el entorno local tenía dependencias enlazadas de forma incompleta.
  • Solución: se reinstalaron dependencias con el gestor apropiado y luego la compilación terminó correctamente.
  1. Problema: ejecución de sqlcmd con error de certificado.
  • Causa: el servidor local requería confiar explícitamente en el certificado para la conexión de prueba.
  • Solución: se ejecutaron los comandos con la opción adecuada para confiar en el certificado y continuar con la recreación de la base.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DUDAS Y DIVERGENCIAS DE CRITERIO

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • Quedó pendiente decidir si la bitácora de eventos debe guardar trazabilidad completa en texto plano o en un formato más estructurado.
  • Se identificó la necesidad de definir qué campos adicionales debe registrar BitacoraEvento para cubrir mejor auditoría de operaciones críticas.
  • Sigue abierta la discusión sobre qué índices y restricciones únicas conviene agregar antes de implementar los procedimientos almacenados principales.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

AVANCE DEL CÓDIGO

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • Se actualizó SQL/SCRIPTS/Tablas.sql con correcciones al modelo físico.
  • Se ajustó src/db/connection.ts para apuntar a la base correcta.
  • Se alinearon controladores del backend con los nombres reales del esquema.
  • Se creó y dejó registrado el archivo AGENTS.md como guía operativa del proyecto.
  • Se generó el documento de auditoría del modelo para dejar constancia de los hallazgos y prioridades.
  • Se validó que la base PlanillaDB pudiera recrearse desde cero a partir del script corregido.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MORALEJAS / BUENAS PRÁCTICAS

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • Revisar siempre el modelo físico contra la especificación antes de crear o volver a crear la base.
  • Alinear nombres de columnas, tablas y parámetros entre SQL y backend desde el inicio evita errores costosos.
  • Validar el script completo de creación después de cada cambio grande, no solo fragmentos aislados.
  • Mantener una guía operativa clara ayuda a que el trabajo sea repetible y más fácil de continuar.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PRÓXIMA SESIÓN: ¿QUÉ SIGUE?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • Implementar los procedimientos almacenados base que consumirá el backend.
  • Definir la estructura final de la tabla de bitácora para auditoría.
  • Agregar índices y restricciones faltantes antes de entrar a pruebas funcionales.
  • Empezar la conexión real entre el listado de empleados y el endpoint del backend.

Comentarios

Publicar un comentario