O que é SQL

O SQL (Structured Query Language) é a linguagem padrão dos bancos de dados relacionais. Ela é declarativa: você descreve o resultado que quer, e o banco decide como obtê-lo. Suas ideias vêm do modelo relacional que Edgar F. Codd publicou em 1970 e da álgebra relacional, que trata tabelas como conjuntos. ^{[2] [3] [4]}

A IBM criou a primeira versão nos anos 1970, e logo surgiram “dialetos” de outros fabricantes. Para organizá-los, o ANSI publicou um padrão em 1986 e a ISO, em 1987; desde então o padrão foi revisto várias vezes. Oracle, SQL Server, PostgreSQL, MySQL e SQLite seguem o núcleo do padrão, mas cada um tem extensões próprias. ^[2]

Os subconjuntos do SQL

Os comandos do SQL costumam ser divididos em grupos, conforme o que fazem. ^[5]

A tabela do original tem alguns erros de sintaxe nos exemplos da DML. Estas são as versões corrigidas:

Sobre transações: COMMIT torna as mudanças permanentes e ROLLBACK as desfaz desde o último COMMIT. No Oracle, uma transação começa sozinha no primeiro comando DML, e todo comando DDL faz um COMMIT implícito. ^[5]

A estrutura do SELECT

A sintaxe do original omite justamente a lista de colunas e tem colchetes desencontrados. A forma geral é: ^[6]

SELECT [DISTINCT] lista_de_colunas
  FROM tabelas_e_junções
 [WHERE condição_sobre_linhas]
 [GROUP BY colunas_de_agrupamento]
 [HAVING condição_sobre_grupos]
 [ORDER BY colunas [ASC | DESC]]

O DISTINCTROW citado no original só existe no MySQL, como sinônimo de DISTINCT. Repare que a ordem em que as cláusulas são escritas não é a ordem em que o banco as avalia:

O original descreve o SELECT como um recorte “horizontal” (as colunas) e “vertical” (as linhas escolhidas pelo critério). Na álgebra relacional, são a projeção e a seleção: ^[3]

Dica: “A perfeição não é alcançada quando não há mais nada a acrescentar, mas quando não há mais nada a retirar”, escreveu Saint-Exupéry (em Terra dos homens, e não em O pequeno príncipe, como diz o original). Em SQL: evite SELECT * e peça só as colunas de que precisa. Menos colunas significam menos dados lidos e transferidos e, às vezes, a chance de responder usando só um índice. ^[1]

Plano de execução

Antes de executar uma consulta, o otimizador do banco monta um plano de execução: em que ordem ler as tabelas, quais índices usar e como juntar os resultados. No Oracle, o plano aparece com EXPLAIN PLAN FOR seguido de SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY), ou pelo botão de plano do SQL Developer. ^[7]

Três números guiam essas escolhas:

• Seletividade: a fração das linhas que passa por um filtro, de 0,0 (nenhuma) a 1,0 (todas).
• Cardinalidade: a estimativa de quantas linhas cada etapa devolve.
• Custo: a estimativa de recursos (leituras de disco, CPU, rede) de cada etapa.

Não aplique funções às colunas filtradas

Uma condição como WHERE TO_CHAR(data, 'YYYY') = '2026' obriga o banco a calcular a função em cada linha e impede o uso de um índice comum sobre data. Prefira transformar o valor, e não a coluna: WHERE data >= DATE '2026-01-01' AND data < DATE '2027-01-01'. Condições escritas assim são chamadas de sargable. ^{[8] [34]}

É o que o original recomenda para o JD Edwards, que guarda datas no formato juliano CYYDDD. Em vez de converter a coluna, converte-se a data de hoje: ixefff <= TO_CHAR(SYSDATE, 'YYYYDDD') - 1900000.

Tabela condutora

O original chama de drive table a tabela pela qual a consulta começa, em geral a mais restritiva. Nos otimizadores atuais, baseados em custo, essa escolha é automática e costuma ser boa quando as estatísticas estão em dia. Quando não é, o Oracle aceita dicas como /*+ LEADING(a) */, que devem ser a exceção, não a regra. ^[7]

Junções e apelidos

Uma junção (JOIN) combina linhas de duas tabelas por uma condição. A figura mostra os tipos principais sobre os mesmos dados. ^{[9] [10]}

O NATURAL JOIN, citado no original, junta automaticamente pelas colunas de mesmo nome. É prático, mas frágil: se alguém acrescentar uma coluna com um nome repetido, a junção muda sem aviso. Prefira escrever a condição com ON.

Junção explícita em vez de implícita

A forma antiga lista as tabelas separadas por vírgula e põe a condição de junção no WHERE. A forma explícita separa o que é junção (ON) do que é filtro (WHERE), o que deixa consultas grandes mais legíveis. No exemplo implícito do original falta o AND entre as duas condições, o que causa erro de sintaxe:

-- implícita (corrigida: faltava o AND)
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a, proddta.f4101 b
 WHERE b.imitm = a.ibitm
   AND a.ibmcu = '     PRODCAN';

-- explícita
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 WHERE a.ibmcu = '     PRODCAN';

Os espaços em ' PRODCAN' não são erro: o JD Edwards guarda o código da filial alinhado à direita, com espaços à esquerda.

A César o que é de César: apelidos

Apelidos (aliases) dão nomes curtos a tabelas e colunas. Eles são obrigatórios quando a mesma tabela aparece duas vezes, como neste exemplo do original, que busca a descrição do kit e a do componente na mesma tabela de itens:

SELECT a.ixkitl,
       b.imdsc1 AS desc_kit,
       a.ixlitm,
       c.imdsc1 AS desc_comp
  FROM proddta.f3002 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ixkit   -- o item kit
 INNER JOIN proddta.f4101 c ON c.imitm = a.ixitm   -- o componente
 WHERE a.ixtbm = 'M'
   AND a.ixmmcu = '     PRODCAN'
   AND a.ixkitl = '7415K00893F';

Subconsultas, IN e EXISTS

Dividir para conquistar

Uma subconsulta é um SELECT dentro de outro. No FROM, ela funciona como uma tabela temporária: no exemplo do original, soma o estoque por item e filial antes da junção. ^[6]

SELECT a.iblitm, b.imdsc1, c.lipqoh
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 INNER JOIN (SELECT liitm, limcu, SUM(lipqoh) AS lipqoh
               FROM proddta.f41021
              GROUP BY liitm, limcu) c
    ON c.liitm = a.ibitm AND c.limcu = a.ibmcu
 WHERE a.ibmcu = '     PRODCAN';

O original mostra que a mesma consulta, escrita com GROUP BY no nível de fora, teve custo e cardinalidade maiores naquele banco. Isso vale para aqueles dados e aquela versão do otimizador; a regra geral é conferir o plano das duas formas.

IN ou EXISTS?

O original cita um texto de 2007 segundo o qual o IN resolve primeiro a subconsulta e o EXISTS primeiro a consulta externa. Nos otimizadores atuais, os dois costumam ser transformados na mesma operação (uma semi-junção) e têm desempenho parecido. A diferença que realmente importa aparece na negação, quando há NULL: ^{[13] [32]}

-- clientes sem pedido; se algum pedido tiver cliente_id NULL…
SELECT nome FROM cliente
 WHERE id NOT IN (SELECT cliente_id FROM pedido);        -- …devolve zero linhas

SELECT nome FROM cliente c
 WHERE NOT EXISTS (SELECT 1 FROM pedido p
                    WHERE p.cliente_id = c.id);          -- devolve Carla

Com um NULL na lista, id NOT IN (1, 2, NULL) nunca é verdadeiro, porque comparar com NULL dá “desconhecido”. Para “não existe”, prefira NOT EXISTS.

Operadores e NULL

No original, os operadores aparecem em imagens de tabelas, em inglês. Aqui eles estão em texto; valem para o Oracle e, com pequenas variações, para os outros bancos: ^{[11] [12]}

A tabela de precedência do original vem de material de treinamento e põe o BETWEEN num nível próprio, abaixo de IS NULL, LIKE e IN. A documentação atual do Oracle agrupa os quatro no mesmo nível, como na figura. Em nenhum dos dois casos isso muda o resultado de uma condição comum; a regra prática é a mesma: NOT, depois AND, depois OR. ^[11]

O NULL não é um valor

NULL significa “desconhecido”. Qualquer comparação com ele dá desconhecido, inclusive NULL = NULL, e o WHERE só deixa passar o que é verdadeiro. Para testar, use IS NULL e IS NOT NULL; para trocar um nulo por um valor, NVL (Oracle) ou COALESCE (padrão). ^[13]

Agregação: GROUP BY e HAVING

As funções agregadas (COUNT, SUM, AVG, MIN, MAX e outras) resumem várias linhas num só valor. Com GROUP BY, calculam um valor por grupo. Toda coluna do SELECT que não está dentro de uma agregação precisa estar no GROUP BY. ^[14]

WHERE ou HAVING?

O WHERE filtra linhas antes do agrupamento; o HAVING filtra grupos depois dele, e por isso pode usar agregações. ^[29]

SELECT employee, SUM(bonus)
  FROM emp_bonus
 GROUP BY employee
HAVING SUM(bonus) > 1000;     -- A 1500 e B 3250

O exemplo “errado” do original, … GROUP BY employee WHERE SUM(bonus) > 1000, falha por dois motivos: o WHERE vem antes do GROUP BY e não aceita agregações. Nos blocos de código do original também sobraram barras invertidas (emp\_bonus), restos da conversão do documento.

Além do GROUP BY simples

O original só indica um artigo sobre agrupamentos em várias dimensões. Em resumo, o Oracle e o padrão SQL oferecem: ^[15]

• GROUP BY ROLLUP(depto): os totais por departamento e mais uma linha de total geral (16000, 13000 e 29000 nos dados deste tutorial).
• GROUP BY CUBE(a, b): os subtotais de todas as combinações de a e b.
• GROUP BY GROUPING SETS ((a), (b), ()): exatamente os agrupamentos listados.

A função GROUPING(coluna) devolve 1 nas linhas de subtotal, para distingui-las de um NULL real nos dados.

Ordem no caos

Sem ORDER BY, nenhum banco garante a ordem das linhas, nem mesmo com GROUP BY ou DISTINCT. Se a ordem importa, peça-a explicitamente; no Oracle, NULLS FIRST ou NULLS LAST decidem onde ficam os nulos. ^[6]

Funções analíticas

O original chama esta parte de “nível Jedi”, e com razão. Uma função analítica (ou de janela) calcula sobre um grupo de linhas, como uma agregada, mas não junta as linhas: cada linha continua no resultado, com o valor calculado ao lado. ^{[16] [17] [33]}

A marca de uma função analítica é a cláusula OVER, que tem três partes opcionais:

função(…) OVER (
    PARTITION BY depto        -- em que grupos calcular
    ORDER BY admissao         -- em que ordem, dentro do grupo
    ROWS BETWEEN …            -- quais linhas entram na conta (a janela)
)

Funções analíticas só podem aparecer na lista do SELECT e no ORDER BY, porque são calculadas depois do WHERE, do GROUP BY e do HAVING. Para filtrar por elas, use uma subconsulta ou um WITH.

Numerar e classificar

Olhar as linhas vizinhas

O mesmo cuidado com a janela explica por que LAST_VALUE costuma “falhar”: com ORDER BY e sem moldura, a janela termina na linha atual, e o último valor é sempre o da própria linha (ou do último empatado com ela). Por isso o exemplo do original escreve ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING, que estende a janela à partição inteira.

Catálogo das funções do original

O original lista as funções analíticas do Oracle 11.2, cada uma com um exemplo agregado e outro analítico. Em resumo, com as correções encontradas: ^[16]

Outros detalhes dos exemplos do original: o comentário do LISTAGG escreve “LISTADD”; o exemplo de COUNT com RANGE BETWEEN 2000 PRECEDING AND 10000 FOLLOWING conta os empregados com salário entre o próprio salário menos 2000 e mais 10000. O SQLite, usado nos testes, não tem LISTAGG; o equivalente é GROUP_CONCAT. ^[18]

Operadores de conjunto

UNION, INTERSECT e EXCEPT combinam os resultados de duas consultas, comparando linhas inteiras. As duas consultas precisam ter o mesmo número de colunas, com tipos compatíveis; os nomes das colunas do resultado vêm da primeira. ^{[20] [21]}

• UNION elimina linhas repetidas, o que exige ordenar ou comparar tudo; quando se sabe que não há repetição, UNION ALL é mais rápido.
• No exemplo do original, a segunda tabela tem colunas person e amount, e não pessoa e quantia. Funciona, porque o que importa é a posição das colunas, mas é mais claro usar os mesmos nomes.
• O texto do EXCEPT diz que a consulta retorna as linhas entre 1 e 100 “além de” as linhas entre 50 e 75. É o contrário: são as linhas entre 1 e 100 exceto as que estão entre 50 e 75.
• No Oracle, o operador se chama MINUS; a partir da versão 21c, EXCEPT, EXCEPT ALL e INTERSECT ALL também são aceitos. ^[21]

Onde não há EXCEPT, dá para obter o mesmo com um LEFT JOIN que mantém só as linhas sem par (WHERE o2.id IS NULL), como mostra o original, ou com NOT EXISTS.

Consultas hierárquicas

Quando cada linha aponta para uma linha-pai da mesma tabela (funcionário e chefe, mensagem e resposta, kit e componente), é preciso uma consulta que percorra a árvore. O exemplo do original é um fórum em que cada mensagem guarda em parent_id o id da mensagem que ela responde. ^{[22] [31]}

CONNECT BY, do Oracle

SELECT LEVEL AS nivel,
       LPAD(' ', (LEVEL - 1) * 3, '-') || m.login || ': ' || m.texto AS mensagem
  FROM mensagem m
 START WITH m.parent_id IS NULL
CONNECT BY PRIOR m.id_mensagem = m.parent_id
 ORDER SIBLINGS BY m.data_envio;

• START WITH define as raízes. O original usa uma subconsulta (id_mensagem IN (SELECT … WHERE parent_id IS NULL)); parent_id IS NULL diretamente faz o mesmo.
• CONNECT BY PRIOR define a relação. O original afirma que o Oracle considera o lado esquerdo da igualdade como pai. Não é bem assim: quem indica o pai é o operador PRIOR, que pode estar de qualquer lado. PRIOR id = parent_id e parent_id = PRIOR id são idênticos; já id = PRIOR parent_id inverte o sentido e sobe da folha para a raiz. ^[22]
• LEVEL é a profundidade; ORDER SIBLINGS BY ordena as respostas de um mesmo pai sem desmontar a árvore; SYS_CONNECT_BY_PATH e CONNECT_BY_ROOT devolvem o caminho desde a raiz e a própria raiz.

Dois detalhes do script do original: TEXTO CLOB DEFAULT '' NOT NULL é contraditório no Oracle, que trata o texto vazio como NULL; e a “Tabela 2” diz ser o resultado da “listagem 2”, mas é o da listagem 3.

A forma padrão: WITH recursivo

O padrão SQL resolve o mesmo problema com um WITH recursivo, aceito pelo Oracle desde a versão 11g R2 e pelos demais bancos atuais. O original diz que o Oracle ainda não o implementava; isso mudou em 2009. Esta versão foi testada no SQLite: ^{[23] [24]}

WITH RECURSIVE arvore (id, login, texto, nivel) AS (
    SELECT id, login, texto, 1
      FROM mensagem WHERE parent_id IS NULL          -- raízes
    UNION ALL
    SELECT m.id, m.login, m.texto, a.nivel + 1
      FROM mensagem m JOIN arvore a ON m.parent_id = a.id  -- filhos
)
SELECT * FROM arvore;

No Oracle, escreve-se só WITH, sem a palavra RECURSIVE. O grande exemplo final do original usa CONNECT BY sobre a lista de materiais do JD Edwards e SYS_CONNECT_BY_PATH para multiplicar as quantidades de cada nível. Com o WITH recursivo, basta levar o produto acumulado numa coluna (a.qtd_acum * m.quantidade), sem as 23 colunas auxiliares.

WITH para consultas complexas

A cláusula WITH (em inglês, subquery factoring ou common table expression) dá nomes a subconsultas, que depois são usadas na consulta principal como se fossem tabelas. Isso deixa consultas longas legíveis e evita repetir a mesma subconsulta. ^{[6] [24]}

O exemplo do original não roda: faltam os parênteses em volta de cada subconsulta e as vírgulas entre elas, há um ponto e vírgula no meio do comando, e a subconsulta por loja usa SUM sem GROUP BY. Corrigido e testado:

WITH
  sum_sales AS (
    SELECT SUM(quantity) AS all_sales FROM sales
  ),
  number_stores AS (
    SELECT COUNT(*) AS nbr_stores FROM store
  ),
  sales_by_store AS (
    SELECT s.store_name, SUM(v.quantity) AS store_sales
      FROM store s JOIN sales v ON v.store_id = s.store_id
     GROUP BY s.store_name
  )
SELECT b.store_name, b.store_sales
  FROM sales_by_store b
 CROSS JOIN sum_sales t
 CROSS JOIN number_stores n
 WHERE b.store_sales > t.all_sales / n.nbr_stores;   -- lojas acima da média

O Oracle decide sozinho se guarda o resultado de cada subconsulta numa tabela temporária (materializar) ou se a incorpora à consulta principal. A dica /*+ MATERIALIZE */ citada no original força a primeira opção, mas não é documentada oficialmente; use-a só depois de comparar os planos.

Variáveis de BIND

Antes de executar um comando, o Oracle procura o texto exato dele na shared pool, uma área de memória compartilhada. Se encontra, reaproveita o plano já calculado (soft parse). Se não, analisa o comando e monta um plano novo (hard parse), o que em sistemas com muitas transações pode custar mais que a própria consulta. ^{[7] [30]}

Uma variável de BIND (:cust_no) substitui o valor literal. O texto do comando fica sempre igual, e só o valor muda a cada execução. Nas linguagens de programação, isso se faz com prepared statements, que têm uma vantagem ainda maior: como o valor nunca é colado no texto do SQL, eles impedem a injeção de SQL. ^{[25] [26] [27]}

Duas dicas finais do original

Para tirar quebras de linha de um campo de texto antes de exportá-lo (dica de Felipe Renz):

SELECT REPLACE(REPLACE(campo, CHR(10), ' '), CHR(13), ' ') FROM …

E as funções de data e hora do SQL Server; no original, faltava um espaço em CURRENT_TIMESTAMPAS:

SELECT GETDATE(), CURRENT_TIMESTAMP, GETUTCDATE(),
       SYSDATETIME(), SYSUTCDATETIME(), SYSDATETIMEOFFSET();

E, como diz a última página do original: Don’t panic!

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “The Hitchhiker’s Guide to the Structured Query Language”, GitHub, texto original deste tutorial, github.com/GiovaniPM/MyCourses/blob/master/SQL/Overview Structured Query Language.md.
2. Wikipedia (em inglês), “SQL”, acesso em 25/09/2026, en.wikipedia.org/wiki/SQL.
3. Wikipedia (em inglês), “Relational algebra”, acesso em 25/09/2026, en.wikipedia.org/wiki/Relational_algebra.
4. Wikipedia (em inglês), “Edgar F. Codd”, acesso em 25/09/2026, en.wikipedia.org/wiki/Edgar_F._Codd.
5. Oracle, SQL Language Reference 19c, “Types of SQL Statements”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Types-of-SQL-Statements.html.
6. Oracle, SQL Language Reference 19c, “SELECT”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SELECT.html.
7. Oracle, SQL Tuning Guide 19c, “SQL Processing”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/tgsql/sql-processing.html.
8. Markus Winand, Use The Index, Luke, “Functions”, acesso em 25/09/2026, use-the-index-luke.com/sql/where-clause/functions.
9. Wikipedia (em inglês), “Join (SQL)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Join_(SQL).
10. Oracle, SQL Language Reference 19c, “Joins”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Joins.html.
11. Oracle, SQL Language Reference 19c, “About SQL Conditions”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Conditions.html.
12. Oracle, SQL Language Reference 19c, “About SQL Operators”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Operators.html.
13. Wikipedia (em inglês), “Null (SQL)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Null_(SQL).
14. Oracle, SQL Language Reference 19c, “Aggregate Functions”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Aggregate-Functions.html.
15. Oracle, Data Warehousing Guide 19c, “SQL for Aggregation in Data Warehouses”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/dwhsg/sql-aggregation-data-warehouses.html.
16. Oracle, SQL Language Reference 19c, “Analytic Functions”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Analytic-Functions.html.
17. Wikipedia (em inglês), “Window function (SQL)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Window_function_(SQL).
18. SQLite, “Window Functions”, acesso em 25/09/2026, sqlite.org/windowfunctions.html.
19. Oracle, SQL Language Reference 19c, “LISTAGG”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/LISTAGG.html.
20. Wikipedia (em inglês), “Set operations (SQL)”, acesso em 25/09/2026, en.wikipedia.org/wiki/Set_operations_(SQL).
21. Oracle, SQL Language Reference 21c, “The Set Operators”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/The-UNION-ALL-INTERSECT-MINUS-Operators.html.
22. Oracle, SQL Language Reference 19c, “Hierarchical Queries”, acesso em 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Hierarchical-Queries.html.
23. Wikipedia (em inglês), “Hierarchical and recursive queries in SQL”, acesso em 25/09/2026, en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL.
24. SQLite, “The WITH Clause”, acesso em 25/09/2026, sqlite.org/lang_with.html.
25. Markus Winand, Use The Index, Luke, “Bind Parameters”, acesso em 25/09/2026, use-the-index-luke.com/sql/where-clause/bind-parameters.
26. Wikipedia (em inglês), “Prepared statement”, acesso em 25/09/2026, en.wikipedia.org/wiki/Prepared_statement.
27. Wikipedia (em inglês), “SQL injection”, acesso em 25/09/2026, en.wikipedia.org/wiki/SQL_injection.
28. Wikipedia (em inglês), “JD Edwards”, acesso em 25/09/2026, en.wikipedia.org/wiki/JD_Edwards.
29. Programmer Interview, “Having vs. Where Clause”, acesso em 25/09/2026, programmerinterview.com/index.php/database-sql/having-vs-where-clause.
30. Akadia, “Oracle Bind Variables”, acesso em 25/09/2026, akadia.com/services/ora_bind_variables.html.
31. DevMedia, “Uso do CONNECT BY no Oracle”, acesso em 25/09/2026, devmedia.com.br/uso-do-connect-by-no-oracle/23647.
32. Oracle Blues, “Diferença entre o IN e o EXISTS”, 2007, acesso em 25/09/2026, oracleblues.blogspot.com/2007/02/diferena-entre-o-in-e-o-exists.html.
33. Certificação BD, “SQL e PL/SQL”, acesso em 25/09/2026, certificacaobd.com.br/category/geral/dbarea/oracle-dbarea/sql-e-plsql.
34. Wikipedia (em inglês), “Sargable”, acesso em 25/09/2026, en.wikipedia.org/wiki/Sargable.

What SQL is

SQL (Structured Query Language) is the standard language of relational databases. It is declarative: you describe the result you want, and the database decides how to get it. Its ideas come from the relational model Edgar F. Codd published in 1970 and from relational algebra, which treats tables as sets. ^{[2] [3] [4]}

IBM built the first version in the 1970s, and other vendors’ “dialects” soon followed. To bring order, ANSI published a standard in 1986 and ISO in 1987; the standard has been revised many times since. Oracle, SQL Server, PostgreSQL, MySQL and SQLite follow its core, but each has its own extensions. ^[2]

The subsets of SQL

SQL commands are usually split into groups according to what they do. ^[5]

The original’s table has a few syntax errors in the DML examples. These are the corrected versions:

On transactions: COMMIT makes changes permanent and ROLLBACK undoes them back to the last COMMIT. In Oracle, a transaction starts by itself with the first DML statement, and every DDL statement performs an implicit COMMIT. ^[5]

The structure of SELECT

The original’s syntax leaves out the column list itself and has mismatched brackets. The general form is: ^[6]

SELECT [DISTINCT] column_list
  FROM tables_and_joins
 [WHERE row_condition]
 [GROUP BY grouping_columns]
 [HAVING group_condition]
 [ORDER BY columns [ASC | DESC]]

The DISTINCTROW mentioned in the original exists only in MySQL, as a synonym for DISTINCT. Notice that the order in which the clauses are written is not the order in which the database evaluates them:

The original describes SELECT as a “horizontal” cut (the columns) and a “vertical” one (the rows chosen by the criteria). In relational algebra these are projection and selection: ^[3]

Tip: “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away”, wrote Saint-Exupéry (in Wind, Sand and Stars, not in The Little Prince, as the original says). In SQL: avoid SELECT * and ask only for the columns you need. Fewer columns mean less data read and transferred and, sometimes, the chance to answer from an index alone. ^[1]

Execution plan

Before running a query, the database optimizer builds an execution plan: in what order to read the tables, which indexes to use and how to join the results. In Oracle, the plan is shown by EXPLAIN PLAN FOR followed by SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY), or by SQL Developer’s plan button. ^[7]

Three numbers drive those choices:

• Selectivity: the fraction of rows that passes a filter, from 0.0 (none) to 1.0 (all).
• Cardinality: the estimate of how many rows each step returns.
• Cost: the estimate of resources (disk reads, CPU, network) for each step.

Do not apply functions to filtered columns

A condition such as WHERE TO_CHAR(hired, 'YYYY') = '2026' makes the database compute the function on every row and prevents the use of a normal index on hired. Transform the value, not the column: WHERE hired >= DATE '2026-01-01' AND hired < DATE '2027-01-01'. Conditions written this way are called sargable. ^{[8] [34]}

That is what the original recommends for JD Edwards, which stores dates in the Julian CYYDDD format. Instead of converting the column, convert today’s date: ixefff <= TO_CHAR(SYSDATE, 'YYYYDDD') - 1900000.

Driving table

The original calls the table a query starts from, usually the most restrictive one, the drive table. Modern cost-based optimizers make that choice automatically and tend to get it right when statistics are up to date. When they do not, Oracle accepts hints such as /*+ LEADING(a) */, which should be the exception, not the rule. ^[7]

Joins and aliases

A join combines rows from two tables through a condition. The figure shows the main kinds on the same data. ^{[9] [10]}

NATURAL JOIN, mentioned in the original, joins automatically on the columns with the same name. It is handy but fragile: if someone adds a column with a repeated name, the join changes silently. Prefer writing the condition with ON.

Explicit rather than implicit joins

The old form lists the tables separated by commas and puts the join condition in WHERE. The explicit form separates what is a join (ON) from what is a filter (WHERE), which keeps large queries readable. The original’s implicit example is missing the AND between its two conditions, which is a syntax error:

-- implicit (corrected: the AND was missing)
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a, proddta.f4101 b
 WHERE b.imitm = a.ibitm
   AND a.ibmcu = '     PRODCAN';

-- explicit
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 WHERE a.ibmcu = '     PRODCAN';

The spaces in ' PRODCAN' are not a mistake: JD Edwards stores the branch code right-aligned, padded with spaces on the left.

Render unto Caesar: aliases

Aliases give short names to tables and columns. They are required when the same table appears twice, as in this example from the original, which fetches the kit’s description and the component’s description from the same item table:

SELECT a.ixkitl,
       b.imdsc1 AS kit_desc,
       a.ixlitm,
       c.imdsc1 AS comp_desc
  FROM proddta.f3002 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ixkit   -- the kit item
 INNER JOIN proddta.f4101 c ON c.imitm = a.ixitm   -- the component
 WHERE a.ixtbm = 'M'
   AND a.ixmmcu = '     PRODCAN'
   AND a.ixkitl = '7415K00893F';

Subqueries, IN and EXISTS

Divide and conquer

A subquery is a SELECT inside another. In FROM, it works as a temporary table: in the original’s example, it adds up stock per item and branch before the join. ^[6]

SELECT a.iblitm, b.imdsc1, c.lipqoh
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 INNER JOIN (SELECT liitm, limcu, SUM(lipqoh) AS lipqoh
               FROM proddta.f41021
              GROUP BY liitm, limcu) c
    ON c.liitm = a.ibitm AND c.limcu = a.ibmcu
 WHERE a.ibmcu = '     PRODCAN';

The original shows that the same query, written with GROUP BY at the outer level, had higher cost and cardinality on that database. That holds for that data and that optimizer version; the general rule is to check the plan of both forms.

IN or EXISTS?

The original quotes a 2007 text saying that IN resolves the subquery first and EXISTS the outer query first. Modern optimizers usually turn both into the same operation (a semi-join), with similar performance. The difference that really matters shows up in negation, when there are NULLs: ^{[13] [32]}

-- customers without orders; if any order has a NULL customer_id…
SELECT name FROM customer
 WHERE id NOT IN (SELECT customer_id FROM orders);   -- …returns zero rows

SELECT name FROM customer c
 WHERE NOT EXISTS (SELECT 1 FROM orders o
                    WHERE o.customer_id = c.id);       -- returns Carla

With a NULL in the list, id NOT IN (1, 2, NULL) is never true, because comparing with NULL yields “unknown”. For “does not exist”, prefer NOT EXISTS.

Operators and NULL

In the original, the operators appear as images of tables. Here they are in text; they apply to Oracle and, with small variations, to other databases: ^{[11] [12]}

The original’s precedence table comes from training material and gives BETWEEN a level of its own, below IS NULL, LIKE and IN. The current Oracle documentation groups all four on one level, as in the figure. Neither version changes the result of an ordinary condition; the practical rule is the same: NOT, then AND, then OR. ^[11]

NULL is not a value

NULL means “unknown”. Any comparison with it yields unknown, including NULL = NULL, and WHERE only lets through what is true. To test for it, use IS NULL and IS NOT NULL; to replace a null with a value, NVL (Oracle) or COALESCE (standard). ^[13]

Aggregation: GROUP BY and HAVING

Aggregate functions (COUNT, SUM, AVG, MIN, MAX and others) summarise many rows into one value. With GROUP BY, they compute one value per group. Every SELECT column that is not inside an aggregate must be in GROUP BY. ^[14]

WHERE or HAVING?

WHERE filters rows before grouping; HAVING filters groups after it, which is why it can use aggregates. ^[29]

SELECT employee, SUM(bonus)
  FROM emp_bonus
 GROUP BY employee
HAVING SUM(bonus) > 1000;     -- A 1500 and B 3250

The original’s “wrong” example, … GROUP BY employee WHERE SUM(bonus) > 1000, fails for two reasons: WHERE comes before GROUP BY and does not accept aggregates. The original’s code blocks also contain stray backslashes (emp\_bonus), leftovers from the document conversion.

Beyond the simple GROUP BY

The original only points to an article on multidimensional grouping. In short, Oracle and standard SQL offer: ^[15]

• GROUP BY ROLLUP(dept): the totals per department plus a grand-total row (16000, 13000 and 29000 with this tutorial’s data).
• GROUP BY CUBE(a, b): subtotals for every combination of a and b.
• GROUP BY GROUPING SETS ((a), (b), ()): exactly the groupings listed.

The GROUPING(column) function returns 1 on subtotal rows, to tell them apart from a real NULL in the data.

Order out of chaos

Without ORDER BY, no database guarantees row order, not even with GROUP BY or DISTINCT. If the order matters, ask for it explicitly; in Oracle, NULLS FIRST or NULLS LAST decides where the nulls go. ^[6]

Analytic functions

The original calls this part “Jedi level”, and rightly so. An analytic function (or window function) computes over a group of rows, like an aggregate, but does not merge them: each row stays in the result, with the computed value next to it. ^{[16] [17] [33]}

The hallmark of an analytic function is the OVER clause, which has three optional parts:

function(…) OVER (
    PARTITION BY dept         -- which groups to compute over
    ORDER BY hired            -- in what order, within the group
    ROWS BETWEEN …            -- which rows count (the window)
)

Analytic functions can appear only in the SELECT list and in ORDER BY, because they are computed after WHERE, GROUP BY and HAVING. To filter on them, use a subquery or a WITH.

Numbering and ranking

Looking at neighbouring rows

The same care with the window explains why LAST_VALUE often seems to “fail”: with ORDER BY and no frame, the window ends at the current row, so the last value is always the row’s own (or that of the last row tied with it). That is why the original’s example writes ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING, stretching the window over the whole partition.

Catalogue of the original’s functions

The original lists Oracle 11.2’s analytic functions, each with an aggregate example and an analytic one. In short, with the corrections found: ^[16]

Other details in the original’s examples: the LISTAGG comment says “LISTADD”; the COUNT example with RANGE BETWEEN 2000 PRECEDING AND 10000 FOLLOWING counts employees whose salary lies between the row’s salary minus 2000 and plus 10000. SQLite, used for the tests, has no LISTAGG; its equivalent is GROUP_CONCAT. ^[18]

Set operators

UNION, INTERSECT and EXCEPT combine the results of two queries by comparing whole rows. Both queries need the same number of columns, with compatible types; the result’s column names come from the first. ^{[20] [21]}

• UNION removes duplicate rows, which requires sorting or comparing everything; when you know there are no duplicates, UNION ALL is faster.
• In the original’s example, the second table has columns person and amount rather than pessoa and quantia. It works, because what matters is the column position, but using the same names is clearer.
• The EXCEPT text says the query returns the rows between 1 and 100 “as well as” the rows between 50 and 75. It is the opposite: the rows between 1 and 100 except those between 50 and 75.
• In Oracle the operator is called MINUS; from version 21c, EXCEPT, EXCEPT ALL and INTERSECT ALL are also accepted. ^[21]

Where there is no EXCEPT, you can get the same with a LEFT JOIN that keeps only unmatched rows (WHERE o2.id IS NULL), as the original shows, or with NOT EXISTS.

Hierarchical queries

When each row points to a parent row in the same table (employee and manager, message and reply, kit and component), you need a query that walks the tree. The original’s example is a forum where each message stores in parent_id the id of the message it replies to. ^{[22] [31]}

Oracle’s CONNECT BY

SELECT LEVEL AS depth,
       LPAD(' ', (LEVEL - 1) * 3, '-') || m.login || ': ' || m.text AS message
  FROM message m
 START WITH m.parent_id IS NULL
CONNECT BY PRIOR m.id = m.parent_id
 ORDER SIBLINGS BY m.sent_at;

• START WITH sets the roots. The original uses a subquery (id_mensagem IN (SELECT … WHERE parent_id IS NULL)); parent_id IS NULL directly does the same.
• CONNECT BY PRIOR sets the relationship. The original claims Oracle treats the left side of the equality as the parent. Not quite: the parent is marked by the PRIOR operator, which can be on either side. PRIOR id = parent_id and parent_id = PRIOR id are identical; id = PRIOR parent_id, however, reverses the direction and climbs from leaf to root. ^[22]
• LEVEL is the depth; ORDER SIBLINGS BY sorts the replies to the same parent without breaking up the tree; SYS_CONNECT_BY_PATH and CONNECT_BY_ROOT return the path from the root and the root itself.

Two details in the original’s script: TEXTO CLOB DEFAULT '' NOT NULL is contradictory in Oracle, which treats the empty string as NULL; and “Table 2” claims to be the result of “listing 2”, but it is the result of listing 3.

The standard way: recursive WITH

Standard SQL solves the same problem with a recursive WITH, supported by Oracle since 11g R2 and by every current database. The original says Oracle had not implemented it yet; that changed in 2009. This version was tested on SQLite: ^{[23] [24]}

WITH RECURSIVE tree (id, login, text, depth) AS (
    SELECT id, login, text, 1
      FROM message WHERE parent_id IS NULL          -- roots
    UNION ALL
    SELECT m.id, m.login, m.text, t.depth + 1
      FROM message m JOIN tree t ON m.parent_id = t.id   -- children
)
SELECT * FROM tree;

In Oracle you write just WITH, without the word RECURSIVE. The original’s big final example uses CONNECT BY over the JD Edwards bill of materials and SYS_CONNECT_BY_PATH to multiply each level’s quantities. With a recursive WITH, you just carry the running product in a column (t.qty_acc * m.quantity), without the 23 helper columns.

WITH for complex queries

The WITH clause (subquery factoring or common table expression) names subqueries that the main query then uses as if they were tables. It keeps long queries readable and avoids repeating the same subquery. ^{[6] [24]}

The original’s example does not run: the parentheses around each subquery and the commas between them are missing, there is a semicolon in the middle of the statement, and the per-store subquery uses SUM without GROUP BY. Corrected and tested:

WITH
  sum_sales AS (
    SELECT SUM(quantity) AS all_sales FROM sales
  ),
  number_stores AS (
    SELECT COUNT(*) AS nbr_stores FROM store
  ),
  sales_by_store AS (
    SELECT s.store_name, SUM(v.quantity) AS store_sales
      FROM store s JOIN sales v ON v.store_id = s.store_id
     GROUP BY s.store_name
  )
SELECT b.store_name, b.store_sales
  FROM sales_by_store b
 CROSS JOIN sum_sales t
 CROSS JOIN number_stores n
 WHERE b.store_sales > t.all_sales / n.nbr_stores;   -- stores above average

Oracle decides by itself whether to store each subquery’s result in a temporary table (materialise it) or merge it into the main query. The /*+ MATERIALIZE */ hint mentioned in the original forces the first option, but it is not officially documented; use it only after comparing plans.

BIND variables

Before running a statement, Oracle looks for its exact text in the shared pool, a shared memory area. If it finds it, it reuses the plan already computed (soft parse). If not, it parses the statement and builds a new plan (hard parse), which on systems with many transactions can cost more than the query itself. ^{[7] [30]}

A BIND variable (:cust_no) takes the place of the literal value. The statement text stays the same, and only the value changes on each run. In programming languages this is done with prepared statements, which bring an even bigger benefit: since the value is never pasted into the SQL text, they prevent SQL injection. ^{[25] [26] [27]}

Two final tips from the original

To strip line breaks from a text field before exporting it (a tip from Felipe Renz):

SELECT REPLACE(REPLACE(field, CHR(10), ' '), CHR(13), ' ') FROM …

And SQL Server’s date and time functions; in the original, a space was missing in CURRENT_TIMESTAMPAS:

SELECT GETDATE(), CURRENT_TIMESTAMP, GETUTCDATE(),
       SYSDATETIME(), SYSUTCDATETIME(), SYSDATETIMEOFFSET();

And, as the original’s last page says: Don’t panic!

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “The Hitchhiker’s Guide to the Structured Query Language”, GitHub, original text of this tutorial (in Portuguese), github.com/GiovaniPM/MyCourses/blob/master/SQL/Overview Structured Query Language.md.
2. Wikipedia, “SQL”, accessed 25 September 2026, en.wikipedia.org/wiki/SQL.
3. Wikipedia, “Relational algebra”, accessed 25 September 2026, en.wikipedia.org/wiki/Relational_algebra.
4. Wikipedia, “Edgar F. Codd”, accessed 25 September 2026, en.wikipedia.org/wiki/Edgar_F._Codd.
5. Oracle, SQL Language Reference 19c, “Types of SQL Statements”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Types-of-SQL-Statements.html.
6. Oracle, SQL Language Reference 19c, “SELECT”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SELECT.html.
7. Oracle, SQL Tuning Guide 19c, “SQL Processing”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/tgsql/sql-processing.html.
8. Markus Winand, Use The Index, Luke, “Functions”, accessed 25 September 2026, use-the-index-luke.com/sql/where-clause/functions.
9. Wikipedia, “Join (SQL)”, accessed 25 September 2026, en.wikipedia.org/wiki/Join_(SQL).
10. Oracle, SQL Language Reference 19c, “Joins”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Joins.html.
11. Oracle, SQL Language Reference 19c, “About SQL Conditions”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Conditions.html.
12. Oracle, SQL Language Reference 19c, “About SQL Operators”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Operators.html.
13. Wikipedia, “Null (SQL)”, accessed 25 September 2026, en.wikipedia.org/wiki/Null_(SQL).
14. Oracle, SQL Language Reference 19c, “Aggregate Functions”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Aggregate-Functions.html.
15. Oracle, Data Warehousing Guide 19c, “SQL for Aggregation in Data Warehouses”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/dwhsg/sql-aggregation-data-warehouses.html.
16. Oracle, SQL Language Reference 19c, “Analytic Functions”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Analytic-Functions.html.
17. Wikipedia, “Window function (SQL)”, accessed 25 September 2026, en.wikipedia.org/wiki/Window_function_(SQL).
18. SQLite, “Window Functions”, accessed 25 September 2026, sqlite.org/windowfunctions.html.
19. Oracle, SQL Language Reference 19c, “LISTAGG”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/LISTAGG.html.
20. Wikipedia, “Set operations (SQL)”, accessed 25 September 2026, en.wikipedia.org/wiki/Set_operations_(SQL).
21. Oracle, SQL Language Reference 21c, “The Set Operators”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/The-UNION-ALL-INTERSECT-MINUS-Operators.html.
22. Oracle, SQL Language Reference 19c, “Hierarchical Queries”, accessed 25 September 2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Hierarchical-Queries.html.
23. Wikipedia, “Hierarchical and recursive queries in SQL”, accessed 25 September 2026, en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL.
24. SQLite, “The WITH Clause”, accessed 25 September 2026, sqlite.org/lang_with.html.
25. Markus Winand, Use The Index, Luke, “Bind Parameters”, accessed 25 September 2026, use-the-index-luke.com/sql/where-clause/bind-parameters.
26. Wikipedia, “Prepared statement”, accessed 25 September 2026, en.wikipedia.org/wiki/Prepared_statement.
27. Wikipedia, “SQL injection”, accessed 25 September 2026, en.wikipedia.org/wiki/SQL_injection.
28. Wikipedia, “JD Edwards”, accessed 25 September 2026, en.wikipedia.org/wiki/JD_Edwards.
29. Programmer Interview, “Having vs. Where Clause”, accessed 25 September 2026, programmerinterview.com/index.php/database-sql/having-vs-where-clause.
30. Akadia, “Oracle Bind Variables”, accessed 25 September 2026, akadia.com/services/ora_bind_variables.html.
31. DevMedia, “Uso do CONNECT BY no Oracle”, accessed 25 September 2026, devmedia.com.br/uso-do-connect-by-no-oracle/23647.
32. Oracle Blues, “Diferença entre o IN e o EXISTS”, 2007, accessed 25 September 2026, oracleblues.blogspot.com/2007/02/diferena-entre-o-in-e-o-exists.html.
33. Certificação BD, “SQL e PL/SQL”, accessed 25 September 2026, certificacaobd.com.br/category/geral/dbarea/oracle-dbarea/sql-e-plsql.
34. Wikipedia, “Sargable”, accessed 25 September 2026, en.wikipedia.org/wiki/Sargable.

Che cos’è SQL

SQL (Structured Query Language) è il linguaggio standard dei database relazionali. È dichiarativo: si descrive il risultato voluto, e il database decide come ottenerlo. Le sue idee vengono dal modello relazionale pubblicato da Edgar F. Codd nel 1970 e dall’algebra relazionale, che tratta le tabelle come insiemi. ^{[2] [3] [4]}

IBM creò la prima versione negli anni ’70, e presto nacquero i “dialetti” di altri produttori. Per metterli in ordine, l’ANSI pubblicò uno standard nel 1986 e l’ISO nel 1987; da allora lo standard è stato rivisto molte volte. Oracle, SQL Server, PostgreSQL, MySQL e SQLite ne seguono il nucleo, ma ognuno ha le proprie estensioni. ^[2]

I sottoinsiemi di SQL

I comandi SQL si dividono di solito in gruppi, secondo ciò che fanno. ^[5]

La tabella dell’originale ha alcuni errori di sintassi negli esempi di DML. Queste sono le versioni corrette:

Sulle transazioni: COMMIT rende definitive le modifiche e ROLLBACK le annulla fino all’ultimo COMMIT. In Oracle una transazione inizia da sola con il primo comando DML, e ogni comando DDL esegue un COMMIT implicito. ^[5]

La struttura della SELECT

La sintassi dell’originale omette proprio l’elenco delle colonne e ha parentesi quadre spaiate. La forma generale è: ^[6]

SELECT [DISTINCT] elenco_colonne
  FROM tabelle_e_join
 [WHERE condizione_sulle_righe]
 [GROUP BY colonne_di_raggruppamento]
 [HAVING condizione_sui_gruppi]
 [ORDER BY colonne [ASC | DESC]]

Il DISTINCTROW citato nell’originale esiste solo in MySQL, come sinonimo di DISTINCT. Notate che l’ordine in cui si scrivono le clausole non è quello in cui il database le valuta:

L’originale descrive la SELECT come un taglio “orizzontale” (le colonne) e “verticale” (le righe scelte dal criterio). Nell’algebra relazionale sono la proiezione e la selezione: ^[3]

Consiglio: “La perfezione si raggiunge non quando non c’è più nulla da aggiungere, ma quando non c’è più nulla da togliere”, scrisse Saint-Exupéry (in Terra degli uomini, non ne Il piccolo principe, come dice l’originale). In SQL: evitate SELECT * e chiedete solo le colonne che servono. Meno colonne significano meno dati letti e trasferiti e, a volte, la possibilità di rispondere usando solo un indice. ^[1]

Piano di esecuzione

Prima di eseguire una query, l’ottimizzatore del database costruisce un piano di esecuzione: in che ordine leggere le tabelle, quali indici usare e come unire i risultati. In Oracle il piano si vede con EXPLAIN PLAN FOR seguito da SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY), oppure con il pulsante del piano di SQL Developer. ^[7]

Tre numeri guidano queste scelte:

• Selettività: la frazione di righe che supera un filtro, da 0,0 (nessuna) a 1,0 (tutte).
• Cardinalità: la stima di quante righe restituisce ogni passo.
• Costo: la stima delle risorse (letture su disco, CPU, rete) di ogni passo.

Non applicate funzioni alle colonne filtrate

Una condizione come WHERE TO_CHAR(assunzione, 'YYYY') = '2026' costringe il database a calcolare la funzione su ogni riga e impedisce l’uso di un indice normale su assunzione. Trasformate il valore, non la colonna: WHERE assunzione >= DATE '2026-01-01' AND assunzione < DATE '2027-01-01'. Le condizioni scritte così si chiamano sargable. ^{[8] [34]}

È ciò che l’originale consiglia per JD Edwards, che memorizza le date nel formato giuliano CYYDDD. Invece di convertire la colonna, si converte la data di oggi: ixefff <= TO_CHAR(SYSDATE, 'YYYYDDD') - 1900000.

Tabella guida

L’originale chiama drive table la tabella da cui parte la query, di solito la più restrittiva. Gli ottimizzatori attuali, basati sui costi, fanno questa scelta da soli e di solito la fanno bene quando le statistiche sono aggiornate. Quando non è così, Oracle accetta suggerimenti come /*+ LEADING(a) */, che dovrebbero essere l’eccezione, non la regola. ^[7]

Join e alias

Un join combina le righe di due tabelle tramite una condizione. La figura mostra i tipi principali sugli stessi dati. ^{[9] [10]}

Il NATURAL JOIN, citato nell’originale, unisce automaticamente sulle colonne con lo stesso nome. È comodo ma fragile: se qualcuno aggiunge una colonna con un nome ripetuto, il join cambia senza avviso. Meglio scrivere la condizione con ON.

Join esplicito invece che implicito

La forma vecchia elenca le tabelle separate da virgole e mette la condizione di join nel WHERE. La forma esplicita separa ciò che è join (ON) da ciò che è filtro (WHERE), e rende leggibili le query grandi. Nell’esempio implicito dell’originale manca l’AND tra le due condizioni, il che è un errore di sintassi:

-- implicito (corretto: mancava l’AND)
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a, proddta.f4101 b
 WHERE b.imitm = a.ibitm
   AND a.ibmcu = '     PRODCAN';

-- esplicito
SELECT a.iblitm, b.imdsc1
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 WHERE a.ibmcu = '     PRODCAN';

Gli spazi in ' PRODCAN' non sono un errore: JD Edwards memorizza il codice della filiale allineato a destra, con spazi a sinistra.

A Cesare quel che è di Cesare: gli alias

Gli alias danno nomi brevi a tabelle e colonne. Sono obbligatori quando la stessa tabella compare due volte, come in questo esempio dell’originale, che prende la descrizione del kit e quella del componente dalla stessa tabella degli articoli:

SELECT a.ixkitl,
       b.imdsc1 AS desc_kit,
       a.ixlitm,
       c.imdsc1 AS desc_comp
  FROM proddta.f3002 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ixkit   -- l’articolo kit
 INNER JOIN proddta.f4101 c ON c.imitm = a.ixitm   -- il componente
 WHERE a.ixtbm = 'M'
   AND a.ixmmcu = '     PRODCAN'
   AND a.ixkitl = '7415K00893F';

Sottoquery, IN ed EXISTS

Dividi e conquista

Una sottoquery è una SELECT dentro un’altra. Nel FROM funziona come una tabella temporanea: nell’esempio dell’originale somma la giacenza per articolo e filiale prima del join. ^[6]

SELECT a.iblitm, b.imdsc1, c.lipqoh
  FROM proddta.f4102 a
 INNER JOIN proddta.f4101 b ON b.imitm = a.ibitm
 INNER JOIN (SELECT liitm, limcu, SUM(lipqoh) AS lipqoh
               FROM proddta.f41021
              GROUP BY liitm, limcu) c
    ON c.liitm = a.ibitm AND c.limcu = a.ibmcu
 WHERE a.ibmcu = '     PRODCAN';

L’originale mostra che la stessa query, scritta con il GROUP BY al livello esterno, aveva costo e cardinalità maggiori su quel database. Vale per quei dati e quella versione dell’ottimizzatore; la regola generale è controllare il piano di entrambe le forme.

IN o EXISTS?

L’originale cita un testo del 2007 secondo cui IN risolve prima la sottoquery ed EXISTS prima la query esterna. Gli ottimizzatori attuali trasformano di solito entrambi nella stessa operazione (un semi-join), con prestazioni simili. La differenza che conta davvero appare nella negazione, quando ci sono dei NULL: ^{[13] [32]}

-- clienti senza ordini; se un ordine ha cliente_id NULL…
SELECT nome FROM cliente
 WHERE id NOT IN (SELECT cliente_id FROM ordine);        -- …restituisce zero righe

SELECT nome FROM cliente c
 WHERE NOT EXISTS (SELECT 1 FROM ordine o
                    WHERE o.cliente_id = c.id);          -- restituisce Carla

Con un NULL nell’elenco, id NOT IN (1, 2, NULL) non è mai vero, perché il confronto con NULL dà “sconosciuto”. Per “non esiste”, preferite NOT EXISTS.

Operatori e NULL

Nell’originale gli operatori compaiono come immagini di tabelle, in inglese. Qui sono in testo; valgono per Oracle e, con piccole variazioni, per gli altri database: ^{[11] [12]}

La tabella di precedenza dell’originale viene da materiale di formazione e mette BETWEEN su un livello a sé, sotto IS NULL, LIKE e IN. La documentazione attuale di Oracle raggruppa i quattro sullo stesso livello, come nella figura. In nessuno dei due casi cambia il risultato di una condizione comune; la regola pratica resta la stessa: NOT, poi AND, poi OR. ^[11]

NULL non è un valore

NULL significa “sconosciuto”. Qualsiasi confronto con esso dà sconosciuto, anche NULL = NULL, e il WHERE lascia passare solo ciò che è vero. Per verificarlo usate IS NULL e IS NOT NULL; per sostituire un nullo con un valore, NVL (Oracle) o COALESCE (standard). ^[13]

Aggregazione: GROUP BY e HAVING

Le funzioni aggregate (COUNT, SUM, AVG, MIN, MAX e altre) riassumono molte righe in un solo valore. Con GROUP BY calcolano un valore per gruppo. Ogni colonna della SELECT che non sta dentro un’aggregazione deve comparire nel GROUP BY. ^[14]

WHERE o HAVING?

Il WHERE filtra le righe prima del raggruppamento; l’HAVING filtra i gruppi dopo, e per questo può usare le aggregazioni. ^[29]

SELECT employee, SUM(bonus)
  FROM emp_bonus
 GROUP BY employee
HAVING SUM(bonus) > 1000;     -- A 1500 e B 3250

L’esempio “sbagliato” dell’originale, … GROUP BY employee WHERE SUM(bonus) > 1000, fallisce per due motivi: il WHERE viene prima del GROUP BY e non accetta aggregazioni. Nei blocchi di codice dell’originale sono rimaste anche delle barre rovesciate (emp\_bonus), residui della conversione del documento.

Oltre il GROUP BY semplice

L’originale rimanda solo a un articolo sui raggruppamenti multidimensionali. In breve, Oracle e lo standard SQL offrono: ^[15]

• GROUP BY ROLLUP(reparto): i totali per reparto più una riga di totale generale (16000, 13000 e 29000 con i dati di questo tutorial).
• GROUP BY CUBE(a, b): i subtotali di tutte le combinazioni di a e b.
• GROUP BY GROUPING SETS ((a), (b), ()): esattamente i raggruppamenti elencati.

La funzione GROUPING(colonna) restituisce 1 nelle righe di subtotale, per distinguerle da un NULL vero nei dati.

Ordine nel caos

Senza ORDER BY, nessun database garantisce l’ordine delle righe, nemmeno con GROUP BY o DISTINCT. Se l’ordine conta, chiedetelo esplicitamente; in Oracle, NULLS FIRST o NULLS LAST decidono dove finiscono i nulli. ^[6]

Funzioni analitiche

L’originale chiama questa parte “livello Jedi”, e a ragione. Una funzione analitica (o di finestra) calcola su un gruppo di righe, come un’aggregata, ma non le unisce: ogni riga resta nel risultato, con il valore calcolato accanto. ^{[16] [17] [33]}

Il segno distintivo di una funzione analitica è la clausola OVER, che ha tre parti facoltative:

funzione(…) OVER (
    PARTITION BY reparto      -- su quali gruppi calcolare
    ORDER BY assunzione       -- in che ordine, dentro il gruppo
    ROWS BETWEEN …            -- quali righe entrano nel calcolo (la finestra)
)

Le funzioni analitiche possono comparire solo nell’elenco della SELECT e nell’ORDER BY, perché sono calcolate dopo WHERE, GROUP BY e HAVING. Per filtrare su di esse usate una sottoquery o un WITH.

Numerare e classificare

Guardare le righe vicine

La stessa attenzione alla finestra spiega perché LAST_VALUE sembra spesso “non funzionare”: con ORDER BY e senza cornice, la finestra finisce alla riga corrente, e l’ultimo valore è sempre quello della riga stessa (o dell’ultima pari con essa). Per questo l’esempio dell’originale scrive ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING, che estende la finestra all’intera partizione.

Catalogo delle funzioni dell’originale

L’originale elenca le funzioni analitiche di Oracle 11.2, ognuna con un esempio aggregato e uno analitico. In sintesi, con le correzioni trovate: ^[16]

Altri dettagli degli esempi dell’originale: il commento di LISTAGG scrive “LISTADD”; l’esempio di COUNT con RANGE BETWEEN 2000 PRECEDING AND 10000 FOLLOWING conta i dipendenti con stipendio compreso tra quello della riga meno 2000 e più 10000. SQLite, usato nei test, non ha LISTAGG; l’equivalente è GROUP_CONCAT. ^[18]

Operatori insiemistici

UNION, INTERSECT ed EXCEPT combinano i risultati di due query confrontando righe intere. Le due query devono avere lo stesso numero di colonne, con tipi compatibili; i nomi delle colonne del risultato vengono dalla prima. ^{[20] [21]}

• UNION elimina le righe ripetute, il che richiede di ordinare o confrontare tutto; quando si sa che non ci sono ripetizioni, UNION ALL è più veloce.
• Nell’esempio dell’originale la seconda tabella ha le colonne person e amount, non pessoa e quantia. Funziona, perché conta la posizione delle colonne, ma è più chiaro usare gli stessi nomi.
• Il testo di EXCEPT dice che la query restituisce le righe tra 1 e 100 “oltre a” quelle tra 50 e 75. È il contrario: le righe tra 1 e 100 tranne quelle tra 50 e 75.
• In Oracle l’operatore si chiama MINUS; dalla versione 21c sono accettati anche EXCEPT, EXCEPT ALL e INTERSECT ALL. ^[21]

Dove non c’è EXCEPT, si ottiene lo stesso con un LEFT JOIN che tiene solo le righe senza corrispondenza (WHERE o2.id IS NULL), come mostra l’originale, oppure con NOT EXISTS.

Query gerarchiche

Quando ogni riga punta a una riga padre della stessa tabella (dipendente e capo, messaggio e risposta, kit e componente), serve una query che percorra l’albero. L’esempio dell’originale è un forum in cui ogni messaggio memorizza in parent_id l’id del messaggio a cui risponde. ^{[22] [31]}

CONNECT BY di Oracle

SELECT LEVEL AS livello,
       LPAD(' ', (LEVEL - 1) * 3, '-') || m.login || ': ' || m.testo AS messaggio
  FROM messaggio m
 START WITH m.parent_id IS NULL
CONNECT BY PRIOR m.id = m.parent_id
 ORDER SIBLINGS BY m.data_invio;

• START WITH definisce le radici. L’originale usa una sottoquery (id_mensagem IN (SELECT … WHERE parent_id IS NULL)); parent_id IS NULL direttamente fa lo stesso.
• CONNECT BY PRIOR definisce la relazione. L’originale afferma che Oracle considera padre il lato sinistro dell’uguaglianza. Non è proprio così: il padre è indicato dall’operatore PRIOR, che può stare da entrambi i lati. PRIOR id = parent_id e parent_id = PRIOR id sono identici; id = PRIOR parent_id, invece, inverte il verso e risale dalla foglia alla radice. ^[22]
• LEVEL è la profondità; ORDER SIBLINGS BY ordina le risposte di uno stesso padre senza smontare l’albero; SYS_CONNECT_BY_PATH e CONNECT_BY_ROOT restituiscono il percorso dalla radice e la radice stessa.

Due dettagli dello script dell’originale: TEXTO CLOB DEFAULT '' NOT NULL è contraddittorio in Oracle, che tratta la stringa vuota come NULL; e la “Tabella 2” dice di essere il risultato del “listato 2”, ma è quello del listato 3.

La forma standard: WITH ricorsivo

Lo standard SQL risolve lo stesso problema con un WITH ricorsivo, supportato da Oracle dalla versione 11g R2 e da tutti i database attuali. L’originale dice che Oracle non lo implementava ancora; questo è cambiato nel 2009. Questa versione è stata verificata su SQLite: ^{[23] [24]}

WITH RECURSIVE albero (id, login, testo, livello) AS (
    SELECT id, login, testo, 1
      FROM messaggio WHERE parent_id IS NULL          -- radici
    UNION ALL
    SELECT m.id, m.login, m.testo, a.livello + 1
      FROM messaggio m JOIN albero a ON m.parent_id = a.id  -- figli
)
SELECT * FROM albero;

In Oracle si scrive solo WITH, senza la parola RECURSIVE. Il grande esempio finale dell’originale usa CONNECT BY sulla distinta base di JD Edwards e SYS_CONNECT_BY_PATH per moltiplicare le quantità di ogni livello. Con un WITH ricorsivo basta portare il prodotto progressivo in una colonna (a.qta_acc * m.quantita), senza le 23 colonne ausiliarie.

WITH per query complesse

La clausola WITH (subquery factoring o common table expression) dà un nome alle sottoquery, che la query principale usa poi come se fossero tabelle. Rende leggibili le query lunghe ed evita di ripetere la stessa sottoquery. ^{[6] [24]}

L’esempio dell’originale non gira: mancano le parentesi attorno a ogni sottoquery e le virgole tra di esse, c’è un punto e virgola in mezzo al comando, e la sottoquery per negozio usa SUM senza GROUP BY. Corretto e verificato:

WITH
  sum_sales AS (
    SELECT SUM(quantity) AS all_sales FROM sales
  ),
  number_stores AS (
    SELECT COUNT(*) AS nbr_stores FROM store
  ),
  sales_by_store AS (
    SELECT s.store_name, SUM(v.quantity) AS store_sales
      FROM store s JOIN sales v ON v.store_id = s.store_id
     GROUP BY s.store_name
  )
SELECT b.store_name, b.store_sales
  FROM sales_by_store b
 CROSS JOIN sum_sales t
 CROSS JOIN number_stores n
 WHERE b.store_sales > t.all_sales / n.nbr_stores;   -- negozi sopra la media

Oracle decide da solo se salvare il risultato di ogni sottoquery in una tabella temporanea (materializzarla) o incorporarla nella query principale. Il suggerimento /*+ MATERIALIZE */ citato nell’originale forza la prima opzione, ma non è documentato ufficialmente; usatelo solo dopo aver confrontato i piani.

Variabili di BIND

Prima di eseguire un comando, Oracle ne cerca il testo esatto nella shared pool, un’area di memoria condivisa. Se lo trova, riusa il piano già calcolato (soft parse). Altrimenti analizza il comando e costruisce un piano nuovo (hard parse), che nei sistemi con molte transazioni può costare più della query stessa. ^{[7] [30]}

Una variabile di BIND (:cust_no) prende il posto del valore letterale. Il testo del comando resta sempre uguale, e cambia solo il valore a ogni esecuzione. Nei linguaggi di programmazione si fa con i prepared statement, che hanno un vantaggio ancora maggiore: poiché il valore non viene mai incollato nel testo SQL, impediscono la SQL injection. ^{[25] [26] [27]}

Due ultimi consigli dell’originale

Per togliere gli a capo da un campo di testo prima di esportarlo (consiglio di Felipe Renz):

SELECT REPLACE(REPLACE(campo, CHR(10), ' '), CHR(13), ' ') FROM …

E le funzioni di data e ora di SQL Server; nell’originale mancava uno spazio in CURRENT_TIMESTAMPAS:

SELECT GETDATE(), CURRENT_TIMESTAMP, GETUTCDATE(),
       SYSDATETIME(), SYSUTCDATETIME(), SYSDATETIMEOFFSET();

E, come dice l’ultima pagina dell’originale: Don’t panic!

Ripasso veloce

Provate a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “The Hitchhiker’s Guide to the Structured Query Language”, GitHub, testo originale di questo tutorial (in portoghese), github.com/GiovaniPM/MyCourses/blob/master/SQL/Overview Structured Query Language.md.
2. Wikipedia (in inglese), “SQL”, consultato il 25/09/2026, en.wikipedia.org/wiki/SQL.
3. Wikipedia (in inglese), “Relational algebra”, consultato il 25/09/2026, en.wikipedia.org/wiki/Relational_algebra.
4. Wikipedia (in inglese), “Edgar F. Codd”, consultato il 25/09/2026, en.wikipedia.org/wiki/Edgar_F._Codd.
5. Oracle, SQL Language Reference 19c, “Types of SQL Statements”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Types-of-SQL-Statements.html.
6. Oracle, SQL Language Reference 19c, “SELECT”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SELECT.html.
7. Oracle, SQL Tuning Guide 19c, “SQL Processing”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/tgsql/sql-processing.html.
8. Markus Winand, Use The Index, Luke, “Functions”, consultato il 25/09/2026, use-the-index-luke.com/sql/where-clause/functions.
9. Wikipedia (in inglese), “Join (SQL)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Join_(SQL).
10. Oracle, SQL Language Reference 19c, “Joins”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Joins.html.
11. Oracle, SQL Language Reference 19c, “About SQL Conditions”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Conditions.html.
12. Oracle, SQL Language Reference 19c, “About SQL Operators”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/About-SQL-Operators.html.
13. Wikipedia (in inglese), “Null (SQL)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Null_(SQL).
14. Oracle, SQL Language Reference 19c, “Aggregate Functions”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Aggregate-Functions.html.
15. Oracle, Data Warehousing Guide 19c, “SQL for Aggregation in Data Warehouses”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/dwhsg/sql-aggregation-data-warehouses.html.
16. Oracle, SQL Language Reference 19c, “Analytic Functions”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Analytic-Functions.html.
17. Wikipedia (in inglese), “Window function (SQL)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Window_function_(SQL).
18. SQLite, “Window Functions”, consultato il 25/09/2026, sqlite.org/windowfunctions.html.
19. Oracle, SQL Language Reference 19c, “LISTAGG”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/LISTAGG.html.
20. Wikipedia (in inglese), “Set operations (SQL)”, consultato il 25/09/2026, en.wikipedia.org/wiki/Set_operations_(SQL).
21. Oracle, SQL Language Reference 21c, “The Set Operators”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/The-UNION-ALL-INTERSECT-MINUS-Operators.html.
22. Oracle, SQL Language Reference 19c, “Hierarchical Queries”, consultato il 25/09/2026, docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Hierarchical-Queries.html.
23. Wikipedia (in inglese), “Hierarchical and recursive queries in SQL”, consultato il 25/09/2026, en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL.
24. SQLite, “The WITH Clause”, consultato il 25/09/2026, sqlite.org/lang_with.html.
25. Markus Winand, Use The Index, Luke, “Bind Parameters”, consultato il 25/09/2026, use-the-index-luke.com/sql/where-clause/bind-parameters.
26. Wikipedia (in inglese), “Prepared statement”, consultato il 25/09/2026, en.wikipedia.org/wiki/Prepared_statement.
27. Wikipedia (in inglese), “SQL injection”, consultato il 25/09/2026, en.wikipedia.org/wiki/SQL_injection.
28. Wikipedia (in inglese), “JD Edwards”, consultato il 25/09/2026, en.wikipedia.org/wiki/JD_Edwards.
29. Programmer Interview, “Having vs. Where Clause”, consultato il 25/09/2026, programmerinterview.com/index.php/database-sql/having-vs-where-clause.
30. Akadia, “Oracle Bind Variables”, consultato il 25/09/2026, akadia.com/services/ora_bind_variables.html.
31. DevMedia, “Uso do CONNECT BY no Oracle”, consultato il 25/09/2026, devmedia.com.br/uso-do-connect-by-no-oracle/23647.
32. Oracle Blues, “Diferença entre o IN e o EXISTS”, 2007, consultato il 25/09/2026, oracleblues.blogspot.com/2007/02/diferena-entre-o-in-e-o-exists.html.
33. Certificação BD, “SQL e PL/SQL”, consultato il 25/09/2026, certificacaobd.com.br/category/geral/dbarea/oracle-dbarea/sql-e-plsql.
34. Wikipedia (in inglese), “Sargable”, consultato il 25/09/2026, en.wikipedia.org/wiki/Sargable.