UniGestión
Ejercicio de persistencia donde la historia es decidir qué dato va en qué base de datos, no el formulario que va encima.
This case study hasn't been translated yet — the text below is in Spanish. Read it on the Spanish site
Outcome
1
archivo de Excel que colapsaba en inscripciones
5
áreas del sistema académico reorganizadas
Más rápido
consultar un historial que antes se armaba a mano
Constraints
- El punto de partida es un único CSV exportado de Excel, con datos de profesores y estudiantes repetidos en cada materia inscrita.
- Las calificaciones históricas se consultan mucho más de lo que se escriben, así que no viven donde viven las inscripciones.
- Partió de un fork del enunciado, no de un repositorio en blanco.
Una universidad que manejaba estudiantes, profesores, cursos, inscripciones, calificaciones y pagos de matrícula en un solo archivo de Excel exportado a CSV. El sistema colapsaba en época de inscripciones.
El ejercicio consiste en normalizar eso a un modelo relacional y decidir qué parte no pertenece ahí. Las inscripciones y los pagos son transaccionales: necesitan integridad referencial y restricciones. Los historiales académicos son otra cosa — se leen mucho, se escriben poco, y armarlos con JOIN cada vez es pagar el mismo costo una y otra vez por un dato que no cambia.
La decisión de qué guardar dónde es la historia completa del proyecto, y no la repite ningún otro repositorio mío salvo LogiTech Solutions, que llega al mismo lugar desde un inventario de retail en vez de un registro académico.
El repositorio partió de un fork del enunciado original, y conviene decirlo: lo mío es la implementación, no el planteamiento del ejercicio.