Creación del SP de Cargar Datos

Fecha: 20 de abril

Hora de inicio: 9:00 a.m. 

Hora de finalización: 12:00 p.m.

Hora de inicio: 1:00 p.m. 

Hora de finalización: 4:00 p.m.

Horas trabajadas: 6h

Con las tablas ya creadas en la base de datos, el siguiente paso era poblarlas con los datos de prueba provistos por el equipo del profesor. Para esto, se debía implementar el script para la carga de datos, que lo hicimos como SP, que recibe el contenido de un archivo XML y lo procesa directamente en SQL Server.


Actividades realizadas

9:00 a.m. - 12:00 p.m.

Antes de escribir el SP, fue necesario investigar cómo SQL Server maneja archivos XML de forma nativa, ya que el profesor indicó en su momento que no debíasmos hacerlo con un parser.

Los conceptos investigados fueron:

  •  nodes () y value(): funciones nativas de SQL Server para procesar XML. nodes() navega la estructura del documento y devuelve una fila por cada nodo encontrado — funciona como un recorrido sobre los elementos. value() extrae el valor de un atributo específico del nodo, indicando además el tipo de dato al que se quiere convertir.

  • Lookups dentro de un INSERT: el XML en algunas partes de datos trae nombres en lugar de ids.  Para resolver esto, se usaron subconsultas dentro del SELECT del INSERT que buscan el id correspondiente al nombre recibido. Básicamente es traducir un nombre a su id dentro de la misma instrucción.
  • Subconsultas correlacionadas: son consultas SELECT anidadas donde la consulta interna depende de un valor de la consulta externa. En este SP se usaron para calcular el NuevoSAldo de cada movimiento -para cada fila de la tabla de movimientos, la subconsulta suma todos los montos del mismo empleado con fecha menor o igual a esa, resultando en el saldo acumulado hasta ese punto en el tiempo.

  • Transacciones en SQL Server: para garantizar consistencia, todo el proceso de carga se envolvió en una transacción. Si cualquiera de los INSERT falla, se revierte todo con ROLLBACK, asegurando que la base de datos no quede en un estado parcialmente cargado.

1:00 p.m. - 4:00 p.m.

Con los conceptos claros, se procedió a implementar el SP. El orden de inserción fue importante dado las dependencias entre tablas (foreign keys):

  1. Puestos
  2. TiposMovimiento
  3. TipoEvento
  4. Usuarios
  5. Errores
  6. Empleados (con lookup de Puesto por nombre)
  7. Movimientos (con lookups de Empleado, TipoMovimiento y Usuario)
  8. Actualización de saldos

Durante las pruebas apareció este error relevante:

Error 1: Bug en el UPDATE de SaldoVacaciones

Al actualizar el SaldoVacaciones de cada empleado, el primer enfoque usaba un JOIN directo entre Empleado y Movimiento. El problema fue que si un empleado tenía varios movimientos, el UPDATE se ejecutaba una vez por cada movimiento, acumulando el saldo incorrectamente. La solución fue agregar una subconsulta con GROUP BY IdEmpleado que calcula el saldo total por empleado de una sola vez, y luego aplica ese resultado en un único UPDATE.

Forma de trabajo del equipo

Este SP fue desarrollado principalmente por mí (JJ), ya que estaba dentro de mis responsabilidades. Sin embargo, Valeria completó las secciones correspondientes a TipoEvento y Error dentro del mismo SP, siguiendo la misma estructura. La coordinación se hizo por WhatsApp.

Buenas prácticas descubiertas

  • Envolver cargas masivas de datos en una transacción garantiza consistencia: si algo falla, no queda ningún dato a medias.
  • Usar SET NOCOUNT ON  al inicio del SP evita que SQL Server envíe mensajes de conteo de filas que pueden interferir con pyodbc al momento de leer resultados.
  • Investigar los conceptos antes de escribir código ahorra tiempo al evitar errores de enfoque desde el inicio.




Referencias









Comentarios

Publicar un comentario

Entradas más populares de este blog

Implementación de funcionalidades: Editar Empleado y Eliminar Empleado

Imagen
Fecha: sábado 25 de abril de 2026 Hora de inicio: 9:30 a.m. Hora de finalización: 5:38 p.m. Horas trabajadas:  4 h 41 min El plan para esta sesión era implementar las funcionalidades completas de editar y eliminar empleado. Fue la sesión más larga del proyecto hasta ahora, con bastante trabajo tanto en capa lógica como en presentación. Actividades realizadas 9:30 a.m. – 10:35 a.m. — Función actualizar_empleado (modelo) Empecé por la función en Python que conecta con el SP ActualizarEmpleado. La estructura es similar a las funciones que ya había hecho: abre la conexión, ejecuta el SP con cursor.execute, lee el resultset con el código de resultado y cierra la conexión en el finally. Un detalle importante en esta función es el conn.commit() después del fetchone. Como ActualizarEmpleado hace un UPDATE dentro de una transacción, es necesario confirmar el cambio desde la capa Python también, de lo contrario la modificación no persiste en la base de datos. Esto ya lo ha...
Leer más

Implementación de funcionalidad: Consultar Empleado

Imagen
Fecha: viernes 24 de abril de 2026 Hora de inicio: 2:30 p.m. Hora de finalización: 7:45 p.m. Horas trabajadas:  3 h 02 min El plan para esta sesión era implementar la funcionalidad completa de consultar empleado: la función en la capa lógica, el controlador y la vista. Johana ya había terminado su parte de capa lógica y presentación días antes, así que yo había esperado a que estuviera lista para arrancar con la mía, tal como lo acordamos. Actividades realizadas 2:30 p.m. – 3:20 p.m. — Función consultar_empleado (capa lógica) Comencé escribiendo la función consultar_empleado en Python. Esto era bastante similar a lo que hice en la tarea 1, así que no partí desde cero: repasé el código de la tarea anterior para refrescar cómo se hacían las llamadas a SPs con pyodbc y cómo se manejaban los resultsets. La función abre la conexión, ejecuta el SP con cursor.execute, lee el primer resultset con cursor.fetchone para obtener los datos del empleado, y luego llama a cursor.nextset() para ...
Leer más