Saltar al contenido principal

UT7 - Persistencia

En programación, la mayoría de estructuras de datos viven en memoria (RAM): variables, listas, diccionarios, etc. El problema es que la memoria es volátil: cuando el programa termina, todo desaparece. La persistencia resuelve esto permitiendo guardar información fuera del programa (disco/base de datos) y recuperarla más tarde, incluso en otra ejecución.

Esta unidad se centra en tres piezas que, en la práctica, van juntas:

  • Ficheros (texto/JSON/CSV y también binarios).
  • Bases de datos (con SQLite como primer paso realista).
  • Excepciones (para que el programa no “reviente” ante problemas inevitables).

1️⃣ Qué es persistencia (y qué no)​

Se entiende por persistencia el proceso de:

  1. Serializar datos (convertir estructuras en algo guardable: texto/bytes/filas en tablas).
  2. Almacenarlos en un soporte estable (fichero, base de datos…).
  3. Deserializarlos después (leerlos y reconstruir la estructura original).

Persistencia no es solo “guardar”: también implica recuperar con fiabilidad, mantener consistencia y gestionar fallos (archivos corruptos, permisos, datos incompletos…).

En esta UT se cubrirán formas habituales:

  • Persistencia en ficheros: JSON/CSV (y ficheros de texto para casos simples).
  • Persistencia en BBDD: SQLite con SQL básico.
  • Persistencia robusta: usando excepciones y buenas prácticas.

2️⃣ Por qué importa en programas reales​

Sin persistencia, una app solo sirve “mientras está abierta”. Con persistencia se habilitan cosas típicas como:

  • Aplicaciones con estado: lista de tareas, favoritos, historial, configuración.
  • Reutilización de resultados: exportar informes, guardar cálculos.
  • Trazabilidad: registrar acciones (logs) para depurar o auditar.
  • Intercambio: CSV/JSON permiten mover datos entre herramientas.
  • Escalabilidad funcional: cuando los datos crecen, una BBDD evita tener que reinventar búsquedas y filtrados.

En resumen: persistencia convierte scripts en programas útiles a medio y largo plazo.

3️⃣ Ficheros vs Base de datos​

No se elige por moda, se elige por necesidad:

Ficheros (JSON/CSV/TXT)

  • Ventajas:

    • Simplicidad (pocos pasos, pocas dependencias).
    • Portabilidad (se copia y listo).
    • Legibilidad (JSON/CSV se pueden abrir y entender).

  • Inconvenientes:

    • Consultas complejas cuestan (filtrar/ordenar requiere cargar y procesar).
    • Riesgo de corrupción si se escribe mal o se interrumpe (hay que cuidar la escritura).
    • Gestión de concurrencia muy limitada (dos procesos escribiendo a la vez = problema).

Base de datos (SQLite)

  • Ventajas:

    • Consultas rápidas y potentes (filtrar/ordenar/agrupar con SQL).
    • Integridad (restricciones: UNIQUE, NOT NULL, relaciones si se diseñan).
    • Transacciones (o se guarda todo, o no se guarda nada).

  • Inconvenientes:

    • Hay que diseñar tablas y aprender SQL mínimo.
    • Errores nuevos (integridad, bloqueos, esquema…).
cómo decidir sin “adivinar”
  • Si los datos son pocos y simples → JSON/CSV.
  • Si crecen, se consultan mucho o hay reglas de integridad → SQLite.

4️⃣ Por qué las excepciones son parte de la persistencia​

Persistir datos implica depender de cosas externas: disco, permisos, rutas, encoding, formato, base de datos… y todo eso puede fallar.

La gestión de excepciones permite:

  • Detectar fallos esperables (archivo no existe, JSON corrupto, tabla no existe).
  • Mantener recursos bajo control (cerrar archivos, cerrar conexiones).
  • Evitar estados inconsistentes (datos guardados “a medias”).
  • Mostrar mensajes útiles: uno para el usuario (claro) y otro para depuración (detallado).

En esta UT se trabajará el enfoque de “fallar bien”: no ocultar errores, sino manejarlos con criterio.