Pregúntale tú a la base de datos

Abre el laboratorio. A la izquierda tienes el esquema: las tablas de la clínica y sus columnas. Es lo primero que mira cualquiera al llegar a una base que no conoce, igual que ls en una máquina.

Hay dos tablas: citas y usuarios.

Escribe esto y pulsa Ejecutar (o Ctrl + Enter):

SELECT * FROM citas

Cuatro filas. Son exactamente las que viste en la pantalla de la agenda interna.

Y ahora sabes lo que pasó de verdad aquella mañana: tu navegador pidió /agenda-interna, el servidor ejecutó una consulta parecida a esta, cogió las filas y con ellas fabricó la tabla que leíste. La página nunca tuvo esos datos: los pidió.

El * significa «todas las columnas». Es cómodo para explorar y se desaconseja en código real, por una razón que ya conoces con otro nombre.

Ahora prueba a pedir dos columnas en vez de todas:

SELECT paciente, hora FROM citas

Mismas cuatro filas, pero sin documento, sin servicio y sin profesional.

Y aquí está la conexión con todo lo que llevas aprendido: eso es el permiso mínimo, en versión SQL.

Si la pantalla solo necesita mostrar quién viene y a qué hora, pedir el documento y el motivo de consulta es traer a la memoria del servidor —y a veces al navegador— datos que nadie iba a usar. Y lo que no se trae no se puede filtrar.

Es el mismo razonamiento que con los permisos de un archivo o los puertos de un servidor: no traigas lo que no necesitas, porque cada dato de más es superficie.

Fíjate además en el detalle que hace grave el escenario de la clínica: la pantalla mostraba Salud mental al lado de un nombre. Eso no era «una columna más». En una clínica, el motivo de consulta es el dato más sensible que hay.

La palabra que hace útil una consulta es WHERE. Filtra.

SELECT * FROM citas WHERE servicio = 'Salud mental'

Una fila. Y lee la nota que sale debajo, porque importa: acabas de averiguar quién va hoy a salud mental. Con una línea. Ese dato, solo, sin nada más, ya es información médica de una persona identificada.

Ahora filtra por documento, que es como lo haría el portal del paciente:

SELECT * FROM citas WHERE documento = '····5209'

Esa es la consulta que el portal ejecutaría para mostrarle a Amparo su cita. Una fila, la suya. En la nota está el código de la sala.

Fíjate en la forma de la consulta, porque es la que vas a romper en la sala siguiente:

... WHERE documento = 'ALGO'

Ese ALGO no lo escribe el programador. Lo escribe quien usa la aplicación.

Queda una tabla por mirar:

SELECT usuario, rol FROM usuarios

Tres usuarios y tres roles distintos: paciente, coordinación, administrador.

O sea que la clínica sí tenía roles. El sistema sabía perfectamente que Amparo es paciente y que la agenda del día es de coordinación. La información estaba ahí, en su base de datos.

Lo que faltaba no era el dato. Era la pregunta: nadie comprobaba el rol antes de servir /agenda-interna.

Y esa es la conclusión de la sala, porque cambia dónde se busca un fallo:

Casi nunca falta la información para decidir. Falta la decisión.

Los roles estaban definidos. Los permisos del archivo existían. La versión del sistema estaba escrita en un archivo. En los tres casos el dato estaba y nadie lo consultó en el momento en que había que consultarlo.