Base de datos
El conjunto organizado de datos y sus reglas.
Del problema empresarial a la capacidad técnica
SQL no sirve únicamente para leer datos.
Descubre cómo una base relacional puede estructurar, controlar, modificar, automatizar, proteger y acelerar la información de una organización.
Práctica disponibleExplicación disponibleLaboratorio en preparación
Cuatro conceptos diferentes
Lenguaje, datos y software no son sinónimos.
SGBD
El software que almacena, controla y ejecuta operaciones.
Servidor
El entorno que ejecuta un servicio de base para sus clientes.
SQL
El lenguaje usado por varios SGBD, con una base común y dialectos.
PostgreSQL, MySQL y SQL Server son SGBD. Utilizan SQL, pero sus tipos, funciones, procedimientos, herramientas administrativas y algunas sintaxis difieren.
12 familias
Empieza por el problema y elige después la herramienta.
Explicación disponiblePrincipiante
Modelar
- Problema empresarial
- Clientes, pedidos y pagos están mezclados o copiados repetidamente.
- Explicación sencilla
- Tablas, tipos, esquemas, claves y relaciones dan lugar y significado a cada hecho.
- Ejemplo
- Un pedido conserva id_client en vez de copiar nombre y dirección del cliente.
- Dialecto
- SQL común; tipos detallados por SGBD
Práctica disponibleDe principiante a avanzado
Consultar
- Problema empresarial
- Un equipo quiere una respuesta reproducible, no un total calculado manualmente.
- Explicación sencilla
- SELECT, filtros, agregaciones, joins, funciones de ventana y CTE convierten una pregunta en un resultado.
- Ejemplo
- Calcular los ingresos por ciudad y clasificar el resultado mayor.
- Dialecto
- Amplia base de SQL común
Explicación disponiblePrincipiante / intermedio
Modificar
- Problema empresarial
- Una aplicación debe registrar una venta, corregir una dirección o eliminar un borrador.
- Explicación sencilla
- INSERT añade, UPDATE modifica y DELETE elimina; UPSERT o MERGE gestiona conflictos según el sistema.
- Ejemplo
- Actualizar el teléfono del cliente identificado sin cambiar otras filas.
- Dialecto
- INSERT/UPDATE/DELETE comunes; UPSERT/MERGE según dialecto
Explicación disponiblePrincipiante / intermedio
Garantizar la integridad
- Problema empresarial
- Un precio negativo, un correo duplicado o un pedido huérfano entra en la base.
- Explicación sencilla
- Tipos, NOT NULL, UNIQUE, CHECK, PRIMARY KEY y FOREIGN KEY rechazan estados no válidos en el lugar adecuado.
- Ejemplo
- CHECK (prix >= 0) rechaza un precio negativo antes de que lo descubra un informe.
- Dialecto
- SQL común con matices
Laboratorio en preparaciónIntermedio
Gestionar transacciones
- Problema empresarial
- Se crea un pedido, pero el pago falla y deja datos incompletos.
- Explicación sencilla
- Una transacción agrupa cambios; COMMIT confirma, ROLLBACK anula y SAVEPOINT permite una recuperación parcial.
- Ejemplo
- Registrar juntos el pedido y su pago, o no registrar ninguno.
- Dialecto
- Base SQL; aislamiento y concurrencia según el SGBD
Explicación disponibleIntermedio
Crear vistas
- Problema empresarial
- Tres informes definen de forma distinta los mismos ingresos mensuales.
- Explicación sencilla
- Una vista da nombre a una consulta reutilizable; una vista materializada conserva un resultado que debe actualizarse.
- Ejemplo
- Exponer ventes_mensuelles a varias herramientas sin copiar la consulta.
- Dialecto
- Vistas ampliamente comunes; materialización según el sistema
Laboratorio en preparaciónIntermedio / avanzado
Automatizar con funciones, procedimientos y triggers
- Problema empresarial
- Cada cambio de precio debe dejar rastro, independientemente del proceso que lo realice.
- Explicación sencilla
- Una función encapsula un cálculo, un procedimiento ejecuta una operación y un trigger reacciona a un evento de tabla.
- Ejemplo
- Tras un UPDATE del precio, guardar OLD.prix y NEW.prix en una tabla histórica.
- Dialecto
- Muy dependiente del SGBD; futuros ejemplos en PostgreSQL
Explicación disponibleIntermedio
Optimizar con índices y EXPLAIN
- Problema empresarial
- La búsqueda de una cuenta por correo se ralentiza al crecer la tabla.
- Explicación sencilla
- EXPLAIN muestra el plan elegido; un índice puede acelerar lecturas añadiendo coste de espacio y escritura.
- Ejemplo
- Comparar el plan antes y después de un índice sobre lower(email).
- Dialecto
- Principios comunes; planes propios del SGBD
Explicación disponibleIntermedio
Proteger con roles y permisos
- Problema empresarial
- Una herramienta de informes debe leer ciertas vistas sin modificar las tablas.
- Explicación sencilla
- Usuarios, roles, GRANT, REVOKE y a veces seguridad por filas aplican el privilegio mínimo.
- Ejemplo
- Conceder SELECT sobre una vista al rol reporting y denegar UPDATE en la tabla fuente.
- Dialecto
- SQL + administración; RLS según el SGBD
Explicación disponibleIntermedio / avanzado
Trabajar con JSON, texto o geografía
- Problema empresarial
- Algunos datos son semiestructurados, textuales o espaciales.
- Explicación sencilla
- JSON/JSONB, búsqueda de texto, tipos geográficos y extensiones amplían los usos cuando son compatibles.
- Ejemplo
- Guardar atributos variables en JSONB e indexar las claves más buscadas.
- Dialecto
- Muy dependiente del sistema y sus extensiones
Explicación disponibleAvanzado
Administrar, respaldar y replicar
- Problema empresarial
- El servicio debe poder restaurarse, supervisarse y seguir disponible ante un fallo.
- Explicación sencilla
- Copia, restauración, replicación, supervisión y alta disponibilidad pertenecen principalmente a la administración del SGBD y la infraestructura.
- Ejemplo
- Probar una restauración desde un dump en vez de suponer que la copia funciona.
- Dialecto
- Herramientas y procedimientos propios del SGBD
Explicación disponibleDe principiante a avanzado
Alimentar aplicaciones y herramientas BI
- Problema empresarial
- Una aplicación, una API y Power BI necesitan definiciones coherentes.
- Explicación sencilla
- SQL selecciona, controla y prepara datos; conectores, API y canalizaciones ETL/ELT los mueven o exponen.
- Ejemplo
- Preparar una vista con granularidad de pedido para Power BI sin duplicar importes.
- Dialecto
- SQL dentro de una arquitectura más amplia
Elige la herramienta más sencilla
¿Cuándo no utilizar un trigger?
Una restricción es suficiente
Para rechazar un precio negativo, CHECK es más visible y directo que una lógica activada.
La lógica quedaría oculta
Un trigger se ejecuta sin aparecer en la consulta que lo llama. Puede sorprender y dificultar la depuración.
El volumen es elevado
Una acción por fila puede ralentizar una modificación masiva. Hay que medir el coste en el caso real.
Puede haber recursión
Un trigger que modifica la misma tabla puede llamarse a sí mismo. Requiere diseño y protecciones explícitas.
Casos adecuados: auditoría, historial y algunas automatizaciones ligadas estrictamente a un evento de datos, tras compararlas con una restricción o la lógica de la aplicación.
¿Empiezas desde cero?
Comienza con una situación sin código y ejecuta tu primera consulta en menos de 45 minutos.