Si llevas semanas escribiendo queries en PostgreSQL y guardándolos sueltos en un notebook, hay una forma mucho más práctica de organizarlos. Las views y functions de pgAdmin te permiten guardar consultas reutilizables dentro de tu propia base de datos, sin depender de archivos externos.

Esto es clave si trabajas con bases como DVD Rentals y necesitas ejecutar reportes recurrentes o lógica compleja sin reescribirla cada vez.

Qué son las views en PostgreSQL y para qué sirven

Dentro de pgAdmin, al lado de la sección de tablas vas a encontrar dos categorías con sus propios contadores: views y functions. En el ejemplo de la clase aparecen 16 tablas, 7 views y 8 functions ya predefinidas en la base [01:00].

Una view es básicamente una query guardada que puedes invocar como si fuera una tabla. En lugar de pegar de nuevo todo el SELECT con sus joins, llamas a la vista por su nombre.

¿Qué es una view en SQL? Es una consulta almacenada que se comporta como una tabla virtual. La invocas con SELECT * FROM nombre_vista y devuelve el resultado de la query original cada vez.

Cómo usar una view ya existente

La base DVD Rentals trae varias vistas listas para usar, como film_list, que combina información de películas con actores. Para consultarla solo escribes:

sql SELECT * FROM film_list;

No necesitas conocer la estructura interna ni los joins que hay detrás. La view ya tiene esa lógica encapsulada [02:00].

Cómo crear tu propia view paso a paso

Para guardar una query como vista, agregas el operador CREATE VIEW antes de tu consulta y le das un nombre descriptivo en minúsculas, siguiendo la convención que ya usa la base:

sql CREATE VIEW clients_employees AS SELECT ...

Al ejecutar esa sentencia, pgAdmin confirma que la query fue exitosa. Haces clic derecho sobre la sección de views, eliges Refresh, y tu nueva vista aparece lista para reutilizarse cuantas veces quieras con un simple SELECT * FROM clients_employees [03:30].

Cómo funcionan las functions en PostgreSQL

Las functions son métodos reutilizables. A diferencia de las vistas, aceptan parámetros y pueden devolver valores calculados, lo que las hace ideales para lógica que cambia según el dato que pases.

Un ejemplo nativo es group_concat, que recibe dos parámetros de tipo texto y los concatena. Puedes invocarla así:

sql SELECT group_concat('Amin', 'Espinosa');

Y también puedes combinarla con columnas reales de tus tablas para concatenar nombres dinámicamente [05:00].

Crear una function personalizada con PL/pgSQL

El ejemplo de la clase crea una función llamada total_pagado_por_cliente que recibe un customer ID como entero y devuelve un valor numérico con la suma de todos los pagos de ese cliente.

Los elementos que necesitas para construirla son:

• Un nombre claro de la función, idealmente que describa qué hace.
• El parámetro de entrada con su tipo, en este caso un integer que representa el ID del cliente.
• El tipo de retorno, que aquí es numérico porque suma montos.
• El lenguaje, que para PostgreSQL suele ser PL/pgSQL.
• Un bloque DECLARE para variables internas, seguido de la rutina entre BEGIN y END.

Dentro de la rutina la lógica es simple: un SELECT SUM(amount) filtrado por el ID recibido, y un RETURN con ese resultado [07:00].

¿Cuál es la diferencia entre una view y una function en PostgreSQL? Una view guarda una query fija que devuelve siempre las mismas columnas. Una function recibe parámetros, ejecuta lógica y puede devolver valores distintos según lo que le pases.

Probar la function con un cliente real

Para validar que funciona, primero buscas un ID válido con SELECT * FROM customer. En el ejemplo se usa el cliente 524. Al invocar la función con ese ID, devuelve el monto total que ese cliente ha pagado en rentas:

sql SELECT total_pagado_por_cliente(524);

El resultado es un único número con la suma acumulada de todos sus alquileres [09:30].

Por qué combinar views y functions acelera tus reportes

La magia aparece cuando juntas ambas herramientas. Si cruzas la function del total pagado con una view que agrupe clientes por nombre y apellido, obtienes un reporte completo: cada usuario identificado, junto al monto exacto que ha gastado en rentas.

Esto te da tres ventajas concretas:

• Velocidad: dejas de reescribir queries largas cada vez que necesitas el mismo dato.
• Consistencia: la lógica vive en un solo lugar, así que si cambias la fórmula, se actualiza para todos los reportes que la usen.
• Personalización: puedes construir reportes muy específicos pasando parámetros distintos a la misma función.

Guardar tus consultas como views y encapsular cálculos en functions convierte a pgAdmin en algo más parecido a una librería de reportes que a un editor de queries sueltos.

¿Qué query de las que ya escribiste convertirías primero en una view? Cuéntalo en los comentarios.