Vas tancar el mòdul 1 amb la base de dades de BotigaVerda carregada i verificada, i amb una promesa: la primera consulta real era a una lliçó de distància. Ja hi som. En aquesta lliçó aprendràs la instrucció més important de SQL, la que faràs servir el 90 % de les vegades que t'asseguis davant d'una base de dades: SELECT. Veuràs com demanar columnes concretes, per què SELECT * és còmode per explorar però perillós en producció, què és realment el conjunt de resultats que et retorna el motor i —el més important a mitjà termini— en quin ordre lògic executa PostgreSQL les clàusules d'una consulta, que no és l'ordre en què les escrius. Aquest últim punt sembla teòric avui i serà la clau per entendre els mòduls 4 i 7.

1. La consulta mínima: SELECT ... FROM ...
2. Seleccionar columnes concretes
3. SELECT *: quan sí i per què en producció no
4. L'ordre de les columnes el decideix el SELECT
5. SELECT sense FROM: SQL com a calculadora
6. Què és realment el conjunt de resultats
7. L'ordre lògic d'execució d'una consulta
8. Llegir resultats a psql i el mode expandit \x
9. Errors habituals i consells
10. Exercicis
11. Conclusió

Una consulta de lectura necessita, com a mínim, dues clàusules:

Llegeix-la en veu alta al revés i entendràs millor el que fa el motor: "de la taula categories, dona'm la columna nom".

En l'argot del model relacional que vas veure a 01-05, SELECT fa una projecció (triar columnes) i, quan hi afegim WHERE a la lliçó 02-03, farem també una selecció (triar files). Que la paraula clau es digui SELECT i faci la projecció és una de les petites incoherències històriques de SQL; convé saber-ho per no confondre's en llegir literatura acadèmica.

Fixa't que no li has dit a PostgreSQL com recórrer la taula, ni en quin fitxer és, ni si convé fer servir un índex. Només has descrit el què. Aquest és el caràcter declaratiu del llenguatge que vam veure a 01-01.

Per demanar diverses columnes se separen amb comes:

20 files. Exactament les 20 que vas carregar a 01-06: SELECT sense filtre retorna totes les files de la taula, i projecta només les columnes que has anomenat. Ni cost, ni stock, ni actiu, ni data_alta hi apareixen: no els has demanat.

Detalls d'escriptura que ja coneixes de 01-03 i que aquí s'apliquen:

• La coma va entre columnes, mai darrere de l'última. SELECT id, nom, FROM productes dona syntax error at or near "FROM".
• Posar una columna per línia no és cap caprici: quan la llista creixi fins a quinze columnes, agrairàs poder afegir-ne o treure'n una sense reescriure la línia sencera.
• Els noms han d'existir. Si escrius SELECT preu_venda FROM productes, PostgreSQL respon column "preu_venda" does not exist. Un \d productes et treu de dubtes en un segon.

L'asterisc significa "totes les columnes de la taula, en l'ordre en què es van definir":

És còmode, i per explorar una taula que no coneixes és el primer que s'escriu. El problema apareix quan aquest * acaba dins d'una aplicació, d'un informe o d'una vista.

Regla del curs: SELECT * per explorar a psql; llista explícita de columnes en qualsevol consulta que vulguis desar, versionar o executar més d'una vegada.

Hi ha una variant intermèdia que sí que és habitual i correcta: SELECT taula.* en consultes amb diverses taules, per dir "totes les columnes d'aquesta taula". La veuràs al mòdul 3.

El resultat no ha de respectar per força l'ordre físic de la taula. Mana la teva llista:

I res no t'impedeix repetir una columna, encara que rarament sigui útil:

Retorna tres columnes, dues de les quals es diuen id. PostgreSQL ho permet; els clients i els llenguatges de programació que hi accedeixen per nom, no sempre. És un avís que, tan bon punt hi hagi noms repetits, faran falta àlies, que és justament el tema de la lliçó següent.

A PostgreSQL la clàusula FROM és opcional. Sense ella, SELECT avalua expressions i retorna una única fila:

Aquesta capçalera ?column? significa "no sé com anomenar això": l'expressió no té nom. S'arregla amb un àlies (lliçó 02-02).

Exemples que faràs servir cada dia per provar coses abans de ficar-les en una consulta gran:

Tres coses que ja es veuen aquí i que reapareixeran:

1. current_date retorna la data del dia en què executis la consulta; el valor de dalt és només un exemple.
2. 12.50 * 1.21 dona 15.1250, amb quatre decimals. PostgreSQL suma les escales dels operands en multiplicar NUMERIC. Per presentar diners caldrà arrodonir (lliçó 02-02).
3. 3 * 12.50 * (1 - 0.05) és el càlcul de l'import de la línia 18 de linies_comanda, amb els números escrits a mà. A la lliçó següent l'escriuràs amb columnes en comptes de literals.

Nota de dialecte: Oracle exigeix un FROM, i per això allà s'escriu SELECT 2+2 FROM dual;. MySQL, SQL Server, SQLite i PostgreSQL admeten SELECT sense FROM.

El que retorna una consulta s'anomena conjunt de resultats (result set) i, conceptualment, és una relació: una taula temporal, sense nom, que existeix només mentre dura la consulta. D'aquí se'n deriven tres propietats que convé interioritzar avui:

1. És una taula com qualsevol altra. Té columnes amb nom i tipus, i files. Per això podrà fer-se servir com a origen d'una altra consulta (subconsultes al FROM, mòdul 7) o combinar-se amb una altra relació (UNION, mòdul 3).
2. No modifica res. SELECT és una operació de només lectura: per moltes vegades que l'executis, la taula original no canvia. Modificar dades és el mòdul 5.
3. No té ordre garantit. Aquesta és la que més sorprèn.

Sobre el tercer punt: al resultat de la secció 2 els productes van sortir ordenats per id, de l'1 al 20. Sembla que la taula "està ordenada". No ho està. Aquest ordre és un efecte col·lateral que les files es van inserir seguides i que PostgreSQL les va llegir en ordre físic. Tan bon punt la taula creixi, s'actualitzin files, entri en joc un índex o el motor faci servir diversos processos en paral·lel, l'ordre pot canviar sense avís i sense que res falli.

La regla és taxativa i no admet excepcions:

Si l'ordre importa, escriu ORDER BY. Si no l'escrius, no tens dret a esperar cap ordre concret.

La clàusula ORDER BY és la lliçó 02-05. Fins llavors, quan en aquesta lliçó o a la següent vegis resultats "ordenats per id", entén que és l'ordre que probablement veuràs, no el que el motor et promet.

Escrius una consulta en un ordre i el motor la resol en un altre. Entendre aquesta diferència és el que després fa evidents coses que altrament semblen arbitràries (per què un àlies funciona a ORDER BY però no a WHERE, per què HAVING existeix a més de WHERE, per què una subconsulta pot veure certes columnes i unes altres no).

Ordre en què s'escriu:

Ordre en què s'executa lògicament:

De moment només fas servir els passos 1 i 3, així que el diagrama sembla exagerat. Desa'l: anirem afegint clàusules a aquest mateix esquema a cada lliçó del mòdul, i al mòdul 4 hi incorporarem GROUP BY i HAVING.

Dues conseqüències que ja pots anticipar:

• Com que WHERE s'executa abans que SELECT, quan arribi el moment de filtrar no podràs fer servir a WHERE un nom inventat al SELECT: encara no existeix.
• Com que ORDER BY s'executa després de SELECT, allà sí que el podràs fer servir.

Un matís important: això és l'ordre lògic, el que defineix el significat de la consulta. El pla real d'execució que tria l'optimitzador pot ser molt diferent (llegir un índex, filtrar mentre llegeix, aturar-se abans d'hora), sempre que el resultat sigui el mateix que el de l'ordre lògic. Els plans reals s'estudien al mòdul 8 amb EXPLAIN.

Quan executes una consulta a psql veus una cosa així:

Peces d'aquesta sortida:

Els booleans s'imprimeixen com a t i f, no com a true/false. En aquest curs els escriurem com a true/false a les taules de resultats per llegibilitat.

Quan una fila té moltes columnes o textos llargs, la sortida es desmunta i es torna il·legible. Per a això hi ha el mode expandit:

Cada fila passa a ocupar un bloc vertical. Es veu perfectament que el client 1 té referit_per_id buit (és NULL: va arribar pel seu compte) i que el client 2 va ser referit pel client 1.

\x alterna entre activat i desactivat; \x auto deixa que psql decideixi segons l'amplada del terminal, i és l'opció més còmoda per al dia a dia.

Altres metaordres que t'estalviaran temps en aquest mòdul:

Tanca la lliçó practicant la projecció sobre les tres taules que més faràs servir.

Qui són els clients i d'on són:

L'equip, amb la seva jerarquia en brut:

Aquí tens el NULL de la Rosa Alcázar Vives, l'única sense cap. Veure'l com una cel·la buida és el teu primer contacte pràctic amb els nuls: el mòdul 4 els dedica una lliçó sencera.

L'estat de les comandes:

Observa que client_id és un número, no un nom. Per saber que la comanda 10 és de la Camille Dubois cal anar a clients, i això exigeix combinar dues taules: és exactament el que fa el JOIN del mòdul 3. Fins llavors treballarem sempre amb una taula cada vegada.

• Coma sobrera abans de FROM. SELECT id, nom, FROM productes → syntax error at or near "FROM". L'error assenyala FROM, però la fallada és a la coma anterior (regla del "mira el token anterior" de 01-03).
• Coma que falta entre columnes. SELECT nom preu FROM productes no dona error: PostgreSQL entén preu com a àlies de nom i retorna una sola columna anomenada preu amb els noms dels productes. És una fallada silenciosa; compta sempre les columnes del resultat.
• column "..." does not exist. Gairebé sempre és una errada o una columna que és en una altra taula. \d taula abans de reescriure a cegues.
• Confondre les cometes. SELECT "nom" FROM productes funciona (identificador en minúscules); SELECT 'nom' FROM productes retorna 20 files amb el text literal nom. No és el mateix.
• Suposar que el resultat ve ordenat. Funciona avui amb 20 files i falla el dia que la taula en tingui un milió. ORDER BY o res.
• Deixar SELECT * al codi. Fes-lo servir per explorar i substitueix-lo per la llista de columnes tan bon punt la consulta sigui definitiva.
• Consell: mira sempre el recompte de files. Si n'esperaves 20 i psql diu (0 files), has après alguna cosa abans de llegir ni una sola cel·la.
• Consell: prova les expressions sense FROM. SELECT 3 * 12.50 * (1 - 0.05); valida el càlcul en un segon, sense soroll de taules.
• Consell: activa \x auto. És la diferència entre llegir una fila de clients i barallar-te amb el terminal.

Escriu una consulta que retorni el nom, el país i l'email de tots els proveïdors. Després respon: quantes files retorna i per què no cal cap filtre per obtenir-les totes?

Sobre empleats, escriu una consulta que mostri les columnes en aquest ordre exacte: carrec, cognoms, nom, ciutat. Justifica per què el resultat no coincideix amb l'ordre en què les columnes estan definides a la taula.

Sense fer servir cap taula, calcula amb SELECT aquestes tres coses i explica el resultat:

1. El preu amb IVA (21 %) del producte 15 (Te verd matcha cerimonial, 22.00 €).
2. L'import de la línia 27 de linies_comanda: 8 unitats a 1.95 € amb un descompte de 0.15.
3. El marge brut del producte 6 (preu 18.90, cost 9.50).

Solució 1

Retorna 5 files. Una consulta sense WHERE no descarta cap fila: el pas 2 de l'ordre lògic simplement no existeix, així que tot el que surt de FROM arriba a SELECT. Fixa't que el proveïdor 5 hi apareix encara que tingui actiu = FALSE: no hi ha res que l'exclogui. Filtrar-lo serà feina de la lliçó 02-03.

Solució 2

El raonament: la taula defineix les columnes com a id, nom, cognoms, carrec, cap_id, salari, data_contractacio, ciutat, però aquest ordre només el fa servir SELECT *. Quan enumeres columnes, l'ordre del resultat és el de la teva llista, perquè la projecció construeix una relació nova amb la forma que tu decideixes. És la mateixa raó per la qual pots ometre columnes o repetir-les.

Solució 3

Tres observacions sobre el raonament:

1. 22.00 * 1.21 dona 26.6200, no 26.62. En multiplicar dos NUMERIC, PostgreSQL suma les escales: dos decimals per dos decimals en donen quatre. Per a un informe caldrà arrodonir.
2. El descompte és una fracció, així que 0.15 és el 15 % i el factor que s'aplica és (1 - 0.15) = 0.85. Escriure 8 * 1.95 * 0.15 donaria el descompte, no l'import. És l'error d'interpretació més freqüent amb aquesta base de dades.
3. La resta 18.90 - 9.50 manté dos decimals, perquè en la suma i la resta l'escala del resultat és la més gran de les dues, no la suma.

(Sí, hem fet servir AS abans d'hora: sense ell les tres columnes es dirien ?column?. És la primera clàusula de la lliçó següent.)

Ja saps interrogar una taula:

• La consulta mínima és SELECT columnes FROM taula;: FROM diu d'on surten les files i SELECT quines columnes es projecten.
• SELECT * serveix per explorar, però en producció se substitueix per la llista explícita de columnes: contracte estable, menys trànsit i millors plans d'execució.
• L'ordre de les columnes del resultat el decideixes tu amb la teva llista, no la definició de la taula.
• SELECT sense FROM converteix PostgreSQL en una calculadora per provar expressions abans d'integrar-les en una consulta.
• El conjunt de resultats és una relació temporal de només lectura i sense ordre garantit: si l'ordre importa, ORDER BY.
• Coneixes l'ordre lògic d'execució FROM → WHERE → SELECT → ORDER BY → LIMIT, que anirem completant a cada lliçó d'aquest mòdul.
• Saps llegir la sortida de psql, comptar files i fer servir el mode expandit \x quan les files són amples.

A la lliçó següent, Àlies, expressions i columnes calculades, deixaràs de limitar-te a retornar el que hi ha desat i començaràs a calcular: preus amb IVA, marges, marges percentuals i l'import d'una línia de comanda, l'expressió que t'acompanyarà durant tot el curs. De passada posaràs un nom decent a aquestes columnes amb AS i descobriràs, gràcies a l'ordre lògic que acabes d'aprendre, per què un àlies funciona en uns llocs i en uns altres no.