Traducción del artículo «It’s not you, it’s SQL» escrito en idioma inglés por Jamie Turner en Stack By Convex el 29 de enero de 2023.
https://stack.convex.dev/not-sql
Los tipos de letra, resaltado, colores y demás han sido colocadas oportunamente por mi persona, Jimmy Olano, traductor.
Y seguimos aprovechando el receso de Carnaval para continuar nuestro estudio del poderoso motor de base de datos relacional PostgreSQL 9.1.
Nuestra miniserie comienza acá y en la última entrada tocamos el tema de las consultas con uniones las cuales utilizaremos aquí también pero con ayuda del programa psql y tal como lo prometimos vamos a trabajar en profundidad por línea de comandos.
Como recordarán ya habíamos utilizado anteriormente a psql para garantizarle al usuario adminsql acceso íntegro a todas las bases de datos en el servidor PostgreSQL que instalamos.
Normalmente lo que hicimos en el párrafo anterior sólamente se hace si hay un solo usuario y una sola base de datos, un sistema pequeño, tal como era a finales del siglo pasado. Pero ahora con computadoras con procesadores multinúcleo (e incluso hasta computadoras con multiprocesador ) un servidor PostgreSQL puede, tranquilamente, atender muchos usuarios a la vez. Imaginemos que en nuestra Academia de Software Libre de ejemplo cada alumno debe acceder a este recurso único pero debemos de cuidar que cada quien trabaje en su propia base de datos y no toque las ajenas, ya sea por error o a propósito (que se ven casos así). Pues bien PostgreSQL soporta usuarios y grupos internamente, tal como si fuera una computadora con un sistema operativo moderno.
Un usuario pudiera ser cada alumno en clase con su base de datos propia para desarrollar su trabajo y aprobar el curso.
Un grupo, por ejemplo, pudiera ser un sección o curso en determinada aula de clase con derechos de sólo lectura sobre una base de datos perteneciente al instructor de clases y además independiente de otros instructores en otras seccionesde clase; eso nos facilita el trabajo al crear usuarios pues se le asigna al grupo y «hereda» la configuración.
Lo comentado en la sección anterior lo veremos ahora de forma práctica y de la manera más sencilla posible. En la máquina Debian que corre nuestro PostgresSQL seleccionamos «Aplicaciones->Accesorios->Terminal»:
Abrimos así una ventana terminal donde procederemos a ingresar el comando psql pero en esta oportunidad lo haremos acompañado de opciones adicionales:
psql --username=adminsql --password --dbname=GNU_academy
Dichas opciones son:
Por ahora ésas son las opciones que utilizaremos por la terminal interactiva pero en realidad psql tiene gran cantidad de agregados los cuales en otras entradas le daremos uso, pero no a todos. Si queréis echar un ojo a la lista completa, pincha aquí.
Una vez hayamos presionado intro y haber tecleado nuestra consabida contraseña al cabo de otro intro nos aparece el siguiente mensaje de error:
psql: FATAL: Peer authentication failed for user «adminsql»
Y no, no es porque hayamos ingresado mal la contraseña, que es harta sencilla sino por el asunto de seguridad que describí hace poco. Para que podamos conectarnos debemos crear un usuario llamado adminsql con su correspondiente contraseña en el sistema operativo Debian (o GNU/Linux que usemos). Esto no sería deseable, ya que los usuarios tendrían acceso al sistema operativo en sí, amén que también si son muchos usuarios recarga inncesariamente el sistema de archivos (que aunque tengamos poderosas computadoras siempre la frugalidad es bienvenida), y no, no necesitamos ése esquema de trabajo.
Es por ello que contamos con la opción peer por defecto, apoyada por el sistema operativo y contamos con la opción md5 que encripta la contraseña para mayor seguridad, así que sólo registraremos usuarios dentro de PostgreSQL. Para ello ganaremos acceso como superusuario y luego usaremos el programa editor de texto nano para editar la configuración. Por favor observen la imagen para que tengan el panorama completo:
nano /etc/postgresql/9.1/main/pg_hba.conf
y buscaremos la sección «is for Unix domain sockets connections only» donde cambiaremos «peer» por «md5» tal como aparece en la siguiente figura:
lo siguiente será (recuerden, estamos usando nano) CTRL+X -> «y» -> intro osea guardar y salir en el editor de textos que hayan utilizado ustedes. Una vez hecho esto, necesitamos que el servidor tome la nueva configuración, en realidad el servicio o demonio debemos reiniciarlo, no la máquina en si:
service postgresql restart
y si hicimos bien nuestro trabajo veremos más o menos lo siguiente:
De nuevo introducimos el comando descrito para conectarnos a la base de datos pero esta vez si que tenemos éxito en nuestra tarea:
Y allí estamos, a la espera de la primera consulta, usaremos entonces la última de la entrada anterior:
SELECT students.name, phone_numbers.number
FROM students
INNER JOIN phone_numbers
ON students.id=phone_numbers.idstudent
WHERE LOWER(students.email) ~ ‘hotmail.com’;
¿Recuerdan la utilidad del punto y coma para indicar el final de la consulta? Acá nos viene como anillo al dedo pues estas terminales son un tanto incómodas al estar generalmente limitadas a 80 columnas, así que presionamos intro y notad que el prompt cambia de «=#» a «-=» para indicarnos que estamos en una sola sentencia a pesar que son varias lineas:
¡Y listo! hemos hecho nuestra primera consulta por terminal interactiva, ya sólo queda salir de psql y luego de nuestra terminal para ello bastará con teclear:
/quit
exit
En la próxima entrada seguiremos trabajando por línea de comandos para la creación de tablas e insertado de datos en las mismas y ampliaremos el estudio de consultas por uniones JOIN.
<Eso es todo, por ahora>.
Esta vez realizaremos unas consultas por uniones no sin antes dar una breve explicación de la integridad referencial, una característica de las bases de datos relacionales, siempre de la manera más sencilla posible.
Para los que el orden es importante esta serie de artículos sobre PostgreSQL 9.1 comienzan acá y la manera de conectarnos al servidor vía phpPgAdmin se describe aquí.
Pues bien, comenzemos ya: tenemos creadas dos tablas llamadas students y phone_numbers y como bien lo describe sus nombres en inglés, sirven para almacenar datos de estudiantes y sus números telefónicos. Como cada persona puede tener varios teléfonos (casa, trabajo, móvil, fax, etc.) y a su vez cada una de esas ubicaciones hoy en día pueden tener varios números diferentes (en mi caso tengo 2 en casa, 3 en el trabajo y uno celular) no tiene sentido crear campos para cada uno de ellos en la tabla students porque no sabemos cuántos va a tener cada inviduo. Cualquiera me puede rebatir diciendo que aunque sea debería suministrar un número de teléfono para alguna emergencia en clase (desde el punto de vista de este ejercicio donde somos una Academia de Software Libre) pero ni con eso contaría yo, es decir, puede darse el caso que no tenga ningún teléfono (hermosa es la película «Enemy of the State» ojalá la disfruten tanto como yo la disfruté en 1999). Es por tanto que en la tabla students no dejamos ningún campo para almacenar el o los que nos suministren y los guardaremos en la tabla phone_numbers teniendo cuidado de guardar de quién es cada cual.
Observemos que al seleccionar la tabla phone_numbers desde phpPgAdmin haciendo click en «constraints» («restricciones») descubriremos el trabajo que hizo Visual Paradigm traduciendo nuestro organigrama a la base de datos:
Como en la entrada anterior agregamos algunos datos de los estudiantes tenemos dicha tabla de ejemplos de la siguiente manera:
De nuevo hacemos click en la tabla phone_numbers e insertamos un registro tal como lo hicimos en la entrada anterior, sólo que en este caso y cuando lleguemos al campo idstudent automáticamente aparecerá una lista de los estudiantes que ya tenemos registrados, en este caso identificados del 1 al 4:
Para probar si la base de datos funciona correctamente en su integridad referencial colocaremos el idstudent = 5 (que aún no está registrado) y le damos click a «insert»:
¡Oh, sorpresa! nos devuelve un mensaje de error y no es para menos ¿para qué querríamos guardar un número de teléfono si no sabemos quién es su propietario? (a menos que trabajeís como detective, hay «caso de casos»).
Desistimos pues en nuestro intento de «embasurar» nuestra base de datos y procedemos a colocarles a los tres números telefónicos que insertemos un idstudent cualquiera entre 1 y 4 y al poco rato tenemos una bonita matrícula lista para clases (aunque falta agregar cursos, aulas, profesores, horarios… «Roma no se construyó en un solo día» reza el refrán, vamos poco a poco).
Una vez hecho esto ya estamos listos para hacer unas consultas entre ambas tablas y con propósitos didácticos ejecutamos la primera consulta (y de manera similar a nuestra entrada anterior):
SELECT students.name, phone_numbers.number
FROM students, phone_numbers
WHERE students.id = phone_numbers.idstudent;
La consulta está en escrita en tres líneas pero la base de datos «sabe» que la misma termina cuando alcanza el punto y coma «;» y dicha manera de escribirla nos proporciona legibilidad para desglosarla y explicarla, línea por línea:
Como sólo insertamos tres números telefónicos pues sólo tres estudiantes con teléfonos será lo que veremos (en este caso para cada estudiante un solo número telefónico que sería el caso más común). ¿Pero y si queremos visualizar TODOS los estudiantes, tengan o no número telefónico registrado?
En el lenguaje SQL existe el comando JOIN con sus prefijos INNER, LEFT y RIGHT haciendo la salvedad que «JOIN» = «INNER JOIN» y será el primero que veremos para realizar la misma consulta que hicimos con el condicional WHERE:
SELECT students.name, phone_numbers.number
FROM students
INNER JOIN phone_numbers
ON students.id=phone_numbers.idstudent;
De nuevo desglosamos y analizamos línea por línea (recordad el para qué sirve el punto y coma al final de la consulta):
Hasta aquí todo bien pero volvamos a la pregunta:
¿Pero y si queremos visualizar TODOS los estudiantes -y su(s) número(s) telefónico(s)-, tengan o no número telefónico registrado?
Es aquí que utilizaremos LEFT JOIN en vez de INNER JOIN, simplemente ese cambio, una sola palabra por otra:
SELECT students.name, phone_numbers.number
FROM students
LEFT JOIN phone_numbers
ON students.id=phone_numbers.idstudent;
Y AHORA SÍ que observamos que el estudiante Pedro aparece pero en donde va el número telefónico muestra NULL el cual es una palabra que encierra un concepto que en base de datos trae aún hoy en día candentes discusiones pero que en este caso práctico muestra su utilidad: «NO TIENE NÚMERO TELEFÓNICO REGISTRADO Y NO SABEMOS SI REALMENTE LO TIENE YA QUE SIMPLEMENTE O SE NEGÓ A SUMINISTRARLO O EL INSCRIPTOR OLVIDÓ REGISTRARLO». Todo eso encierra el concepto de NULL.
Actualizado el martes 12 de enero de 2016: me hacen la sugerencia que pudieramos colocar un campo lógico (verdadero o falso) para saber a ciencia cierta si la persona posee algún teléfono. No veo mala esa idea pero recomiendo que le coloquen NULL como valor predeterminado pero que sea obligatorio ese dato -y por ende no permitirá guardar con NULL-. A nivel de la interfaz del usuario, el formulario que introduce datos para agregar personas deberá utilizarse un RADIO BUTTON sin valor preseleccionado en ninguno de los dos. Ejemplo:
Ya cerrando la entrada podemos acotar la consulta JOIN con un simple WHERE tal como ejercitamos en otra entrada:
SELECT students.name, phone_numbers.number
FROM students
LEFT JOIN phone_numbers
ON students.id=phone_numbers.idstudent
WHERE LOWER(students.email) ~ ‘hotmail.com’;
sólo que esta vez veremos sólamente los estudiantes que posean correo electrónico en «hotmail.com» (hoy día «outlook.com») y que tengan al menos un número telefónico registrado.
En la próxima entrada veremos y estudiaremos cuáles otras opciones existen sobre JOIN, tan importante es que en Wikipedia en castellano tiene su propia entrada completa.
<Eso es todo, por ahora>.
Aprovecho el breve receso de estas fechas carnestolendas de 2015 para continuar con esta miniserie de artículos sobre PostgreSQL 9.1. Para aquellos que quieran llevar la secuencia correcta del tema éste se inicia acá .
La fotografía que veís y que encabeza esta entrada es la del Doctor Donald Chamberlin, investigador de la IBM quien junto al Doctor Raymond Boyce (quien falleció en 1974 y muy poquísimas fotografías dejó) ambos idearon (y nos legaron) el «Structured Query Language» (SQL).
Lo que haremos hoy son unas consultas sencillas en SQL no sin antes haber agregado unos cuantos datos de prueba (cualquier semejanza con personas reales es pura y casual coincidencia).
Utilizando el navegador web predeterminado en Debian, el Iceweasel (que cada día aprecio más por su economía de recursos y por ende rapidez) nos vamos a la consabida dirección IP de nuestro servidor virtual:
Introducimos el «login» y la contraseña (si no lo recuerdan ir a esta entrada ) y una vez hayamos logrado acceso hacemos click («o vamos») a la tabla students (aunque soy fanático del castellano, debo reconocer que el inglés es hoy en día lo que fue el latín en el mundo entero) y observamos su estructura de datos más sin embargo nos interesa, por ahora, el enlace «insert» para dar algunas altas en la tabla:
Tras lo cual se nos abre el siguiente cuadro de diálogo el cual procedemos a llenar sin cortapisa:
Observen que dejé el campo «id» intencionalmente en blanco: nuestro primer valor será, naturalmente, el 1 pero en los siguientes registros que insertemos intenten guardar ese valor de nuevo y observarán una de las restricciones de la tabla: los valores no pueden repetirse para ese campo en particular. A la final verán algo parecido a esto, ya con los registros insertados:
Vuelvo a repetir: cualquier parecido con los datos personales en la realidad es simple y feliz coincidencia. Ahora que tenemos unos cuantos registros insertados podemos hacer unas consultas sencillas, para ello bastará con hacer click en el enlace «SQL» que está en el borde superior derecho de la web, cerquita de
«SQL | History |Find | Logout»
¿lo vieron? en el cuadro de diálogo que se abre escribimos la siguiente sentencia para visualizar los correos electrónicos de los estudiantes:
select email from students;
Antes que hagan click en «execute» («ejecutar -sentencia-«) observen atentamente que estamos trabajando con la base de datos «GNU_academy» y que nuestro vía de búsqueda de esquema está apuntada a «public» (ésto último permite que al ejecutar una sentencia SQL los nombres de tablas y campos sean buscados y verificados primero antes de comenzar a buscar datos, e incluso es útil para asuntos de seguridad y privilegios pero ese tema es más avanzado; si luego quieren aprender más sobre ello aquí el enlace introductorio al asunto ).
Así pues, sin más, ejecutamos la sentencia tras lo cual veremos algo parecido a esto:
La explicación breve de la sentencia SQL es traducirla del inglés:
«select»->»selecciona»
«from»->»desde (la tabla)»
«;»-> indica fin de la sentencia, no es obligatorio pero es útil si vamos a introducir varias sentencias que deben ir en un orden específico (por ejemplo insertar más datos de estudiantes y luego mostrarlos en un listado para asistencia -ya le vamos dando utilidad en la vida real a esto de las bases de datos-).
Como hay comandos específicos del lenguaje SQL yo opto (y hay varias personas que lo hacen) por escribir dichos comandos en mayúsculas y los nombres de tablas (y/o variables y/o constantes) en minúsculas y como pueden ver se ejecutan sin ningún problema, el asunto es de legibilidad para nosotros los humanos:
SELECT email FROM students;
Importante: los nombres de campos y tablas han escribirse tal cual fueron creados en la base de datos correspondiente, de no ser así nos devuelve error; es por ello que desde un principio en estos tutoriales los creamos todos en minúsculas -y en inglés, de paso-.
Volviendo al tema de la realidad, supongamos que por cualquier razón necesitamos saber cúales (y cuántos) estudiantes utilizan correo hotmail pues simplemente introducimos la siguiente sentencia SQL
SELECT email FROM students WHERE email ~ ‘hotmail.com’;
Observen el nuevo comando
«WHERE»->»donde (satisfazga la condición)»
y el uso de la virgulilla como comparador lógico indicando que dicha condición tenga la cadena de texto ‘hotmail.com’. Otros detalles a considerar es el uso de las comillas simples y el uso de mayúsculas: si usamos comillas dobles se interpreta como nombre de columna y si usamos mayúsculas NO devuelve los correos electrónicos ya que «hoTMail.com» NO ES IGUAL A «hotmail.com»:
«hoTMail.com» <> «hotmail.com»
Esto nos plantea desde ya nuevos retos: si vamos a desarrollar una aplicación seria es deber que los usuarios ingresen direcciones de correo válidos (sintaxis usuario@dominio ):
Y son sólo algunas de las reglas que aplican a la sintaxis de una dirección de correo electrónico, para mayor información (en inglés, ¡cuando no!) en RFC 822 y dirección de correo electrónico . La buena noticia es que PosgreSQL admite varios lenguajes de programación que junto con triggers o «disparadores» nos permitirán capturar y revisar los correos electrónicos antes de agregarlos a la base de datos (serán tratados a futuro en una entrada aparte). Y aunque nos hemos salido un poco de las consultas sencillas era necesario ir abonando el terreno hacia temas más avanzados (oh idioma castellano, qué poético eres, nunca cambies 😉 ).
Os ruego hagan la prueba escribiendo las sentencias en sus múltiples variantes, como ayuda os dejo el comando LIKE cuyo uso tiene una sintaxis más elaborada:
SELECT email FROM students WHERE email LIKE ‘%hotmail.com%’;
Produciendo el mismo resultado que con la virgulilla; vale destacar que al colocar el símbolo de porcentaje como comodín le estamos ordenando que nos busque cualquier dirección de correo electrónico registrado en nuestra tabla students que contenga la cadena de caracteres «hotmail.com» (obsérvese que si algún bromista registrara la dirección de correo electrónico «hotmail.com@gmail.com» sería devuelta también en la consulta, os animo a probarla -aunque dudo que alguien en verdad tenga ésa dirección-) pero eso aún no resuelve nuestro problema de mayúsculas y minúsculas.
Una solución sería utilizar una función integrada por defecto en nuestra base de datos, es decir, una serie de programas ya registrados y de propósito general; dicha función para este caso es LOWER() aplicado al campo email (ojo que si es así lo que entrecomillamos como condición debe ir todo en minúsculas):
SELECT email FROM students WHERE LOWER(email) LIKE ‘%hotmail.com%’;
o también podemos usar, como al principio, la virgulilla que nos ahorra el uso de comodines:
SELECT email FROM students WHERE LOWER(email) ~ ‘hotmail.com’;
Si quereís ver el resto de funciones de cadena, haced click aquí.
Por último, si quiséramos el caso contrario, listar los estudiantes que no tienen correo «hotmail» registrado:
SELECT email FROM students WHERE LOWER(email) !~ ‘hotmail.com’;
y lo único que hicimos fue agregarle el operador lógico «!» que indica negación «NOT», el cual si que lo podemos usar con LIKE:
SELECT email FROM students WHERE LOWER(email) NOT LIKE ‘%hotmail.com%’;
Y entonces nos desconectamos de la base de datos como es debido:
<Eso es todo, por ahora>.