Vistas en MySQL: consultas guardadas como tablas

Hola, ¿cómo están? Empezamos los temas complementarios del curso de MySQL, con cinco lecciones sobre cosas que no estaban en el temario y que vas a necesitar en cualquier proyecto real.

Arrancamos con las vistas.

¡Empecemos!

Qué es una vista

Una vista es una consulta guardada a la que se accede como si fuera una tabla.

No almacena datos: guarda la definición de la consulta. Cada vez que la usas, MySQL ejecuta la consulta original por debajo.

CREATE VIEW v_citas_completas AS
SELECT
    c.id,
    c.fecha,
    c.hora,
    CONCAT(p.nombre, ' ', p.apellido) AS paciente,
    CONCAT(d.nombre, ' ', d.apellido) AS doctor,
    e.nombre AS especialidad,
    c.costo,
    c.estado
FROM citas c
JOIN pacientes p ON c.paciente_id = p.id
JOIN doctores d ON c.doctor_id = d.id
JOIN especialidades e ON d.especialidad_id = e.id;

Y a partir de ahí:

SELECT * FROM v_citas_completas WHERE estado = 'programada';

Esa consulta con tres JOIN que escribimos en la lección de JOIN ahora se usa en una línea.

Para qué sirven

Simplificar consultas complejas. Si un JOIN de cuatro tablas se repite en diez lugares del sistema, una vista lo centraliza. Cambias la definición en un sitio y todos se benefician.

Controlar el acceso a los datos. Este es el uso más valioso y menos conocido, y lo vemos abajo.

Dar nombres comprensibles. Un reporte que consulta v_ingresos_mensuales se lee mucho mejor que uno con la consulta completa incrustada.

Mantener compatibilidad. Si cambias la estructura de una tabla, puedes crear una vista con el nombre y las columnas antiguas para que el código existente siga funcionando mientras lo migras.

Vistas para control de acceso

Aquí está la aplicación que de verdad justifica aprenderlas.

Imagina que el área de reportes necesita consultar pacientes, pero no debe ver la cédula ni el teléfono:

CREATE VIEW v_pacientes_publico AS
SELECT
    id,
    nombre,
    apellido,
    TIMESTAMPDIFF(YEAR, fecha_nacimiento, CURDATE()) AS edad
FROM pacientes;

Y ahora, aplicando lo que vimos en la lección de seguridad:

GRANT SELECT ON clinica.v_pacientes_publico TO 'reportes'@'localhost';

Ese usuario no tiene permiso sobre la tabla pacientes, solo sobre la vista. Es imposible que acceda a los datos sensibles, aunque escriba la consulta a mano.

Lo mismo funciona a nivel de filas:

CREATE VIEW v_citas_activas AS
SELECT * FROM citas WHERE estado <> 'cancelada';

Vistas con agregación

Muy útiles para paneles de control:

CREATE VIEW v_ingresos_por_especialidad AS
SELECT
    e.nombre AS especialidad,
    COUNT(c.id) AS total_citas,
    SUM(c.costo) AS ingresos,
    ROUND(AVG(c.costo), 2) AS promedio
FROM citas c
JOIN doctores d ON c.doctor_id = d.id
JOIN especialidades e ON d.especialidad_id = e.id
WHERE c.estado = 'atendida'
GROUP BY e.id, e.nombre;

SELECT * FROM v_ingresos_por_especialidad ORDER BY ingresos DESC;

Toda la lógica del reporte queda encapsulada.

Gestionar vistas

-- Listar las vistas de la base
SHOW FULL TABLES WHERE Table_type = 'VIEW';

-- Ver la definición
SHOW CREATE VIEW v_citas_completas;

-- Modificar
CREATE OR REPLACE VIEW v_citas_completas AS
SELECT ...;

-- Eliminar
DROP VIEW IF EXISTS v_citas_completas;

CREATE OR REPLACE es lo que usarás para actualizar una vista sin tener que borrarla antes.

Sobre nombres: una convención habitual es prefijarlas con v_ o vista_. Ayuda a distinguirlas de las tablas reales cuando listas la base.

Vistas actualizables

Bajo ciertas condiciones puedes hacer INSERT, UPDATE y DELETE sobre la vista, y los cambios afectan a la tabla real:

CREATE VIEW v_pediatras AS
SELECT id, nombre, apellido, telefono
FROM doctores
WHERE especialidad_id = 2;

UPDATE v_pediatras SET telefono = '70011999' WHERE id = 2;

Para que sea actualizable, la vista no puede tener:

• GROUP BY ni funciones de agregación
• DISTINCT
• UNION
• Subconsultas en el SELECT

En la práctica, las vistas de reportes casi nunca son actualizables, y está bien: para eso están las tablas.

WITH CHECK OPTION

Impide que a través de la vista se inserten filas que después no serían visibles en ella:

CREATE VIEW v_pediatras AS
SELECT * FROM doctores WHERE especialidad_id = 2
WITH CHECK OPTION;

-- Falla: quedaría fuera de la vista
INSERT INTO v_pediatras (nombre, especialidad_id) VALUES ('Ana', 1);

Sin esa cláusula, la fila se insertaría y desaparecería de la vista, que es bastante desconcertante.

Las limitaciones de rendimiento

Aquí hay que ser honesto, porque es donde las vistas decepcionan a quien espera magia.

Una vista no acelera nada. No guarda resultados: cada consulta ejecuta la definición completa. Si la consulta original tardaba tres segundos, la vista también.

Los filtros no siempre se optimizan bien. Esto es lo importante:

SELECT * FROM v_ingresos_por_especialidad WHERE especialidad = 'Pediatría';

Uno esperaría que MySQL filtre antes de agrupar. Pero con vistas que llevan GROUP BY, muchas veces calcula la vista entera y filtra después. Con tablas grandes, la diferencia es enorme.

Si el rendimiento importa, comprueba siempre con EXPLAIN qué está haciendo realmente.

MySQL no tiene vistas materializadas. Otros gestores permiten guardar el resultado calculado y refrescarlo periódicamente. En MySQL hay que simularlo con una tabla real que se actualiza con una tarea programada:

CREATE TABLE resumen_mensual AS
SELECT ... FROM ... GROUP BY ...;

Es lo que se hace en paneles con millones de registros: calcular una vez por noche en lugar de en cada carga de página.

Vistas anidadas

Una vista puede consultar otra:

CREATE VIEW v_citas_abril AS
SELECT * FROM v_citas_completas
WHERE fecha BETWEEN '2026-04-01' AND '2026-04-30';

Funciona, pero no abuses. Tres o cuatro niveles de vistas anidadas hacen que sea muy difícil entender qué consulta se está ejecutando realmente, y el optimizador lo maneja peor.

Cuándo usar vistas y cuándo no

Sí:

• Encapsular consultas complejas que se repiten.
• Restringir columnas o filas por usuario.
• Dar nombres claros a reportes.
• Mantener compatibilidad tras un cambio de estructura.

No:

• Esperando que mejoren el rendimiento.
• Anidando varios niveles.
• Como sustituto de una capa de la aplicación. Si la lógica es de negocio, va en tu código.

Errores comunes

• Creer que una vista guarda datos y acelera consultas.
• Filtrar sobre vistas con GROUP BY sin comprobar el plan con EXPLAIN.
• Anidar vistas en cadena.
• Olvidar WITH CHECK OPTION en vistas actualizables.
• No dar permisos correctamente: conceder acceso a la vista pero también a la tabla base anula la protección.

Para cerrar

Las vistas son una herramienta de organización y de seguridad, no de rendimiento. Su mejor uso es dar a cada usuario exactamente los datos que le corresponden, sin que pueda ver el resto.

En la siguiente lección veremos los procedimientos almacenados.

Saludos y éxitos.