A primeira consulta útil
O que você vai aprender
- escrever consultas com uma lista explícita de colunas depois do
SELECTe um filtro de linhas comWHERE - traduzir uma pergunta de negócio para SQL pelo roteiro: entidade →
FROM, restrições →WHERE(comAND), saída →SELECT, ordem →ORDER BY - explicar por que
SELECT *é má prática em consultas de produção - conferir a consulta recontando-a em voz alta: se o reconto bate com a pergunta original, a consulta faz sentido
O mapa foi estudado — e QUERY muda as regras. Até agora você observava o arquivo inteiro como um turista; um arquivista trabalha de outro jeito. No holopainel, tudo se apaga, exceto uma tabela, e surge uma tarefa: faça a sua pergunta de modo que a resposta não traga nenhuma linha nem coluna a mais.
Escolhendo as colunas e as linhas de que você precisa
Pegar tudo com * é cômodo no primeiro contato, mas no trabalho real é como levar o estoque inteiro até o caixa. Em geral, você precisa de campos específicos: liste-os, separados por vírgula, depois do SELECT.
Com as linhas é a mesma coisa: em vez da vitrine inteira, escolha só o segmento de que precisa usando WHERE. Por exemplo, vamos pedir ao «Kotomarket» apenas os produtos da categoria Livros:
Choosing the columns and rows you need
Grabbing everything with * is convenient for a first look, but in real work it’s like hauling the entire warehouse up to the checkout. Usually you need specific fields: list them, comma-separated, after SELECT.
It’s the same with rows: instead of the whole storefront, pick only the segment you need via WHERE. For example, let’s ask Kotomarket for only the products in the Books category:
| name | price |
|---|---|
| SQL для профи | 1290.00 |
| Чистый код | 1490.00 |
| Алгоритмы на практике | 1690.00 |
Da pergunta de negócio para a consulta
As perguntas reais não chegam ao arquivista em SQL: «quais livros custam menos de mil e quinhentos?», «quais eletrônicos custam mais de 5000?». A tradução segue sempre o mesmo roteiro:
- Entidade → tabela. Sobre o que é a pergunta: produtos, compradores, pedidos? «Livros abaixo de 1500» é sobre produtos, então
FROM products. - Restrições → WHERE. Cada condição da pergunta vira uma condição de filtro separada: categoria «Livros», preço menor que 1500.
- O que mostrar → SELECT. O que a pessoa quer ver na resposta? O nome e o preço — são esses que listamos; o resto é ruído.
- Forma da resposta → ORDER BY. «Do barato para o caro» pede uma ordenação por preço.
-- «Quais livros custam menos de 1500 e quanto, do barato para o caro?»
SELECT name, price
FROM products
WHERE category = 'Книги' AND price < 1500
ORDER BY price;
Várias condições se unem pela palavra AND — vamos detalhar os operadores de filtro no próximo capítulo.
E aqui entra o hábito inverso de um bom arquivista: leia a consulta pronta em voz alta, como uma frase. «Dos produtos, pegar os livros abaixo de 1500, mostrar o nome e o preço, ordenar por preço» — se o reconto bate com a pergunta original, a consulta faz sentido. Se no reconto surgir «todas as colunas» ou «a vitrine inteira» — volte e estreite.
Interview question
Pergunta de entrevista: por que SELECT * é considerado má prática em consultas de produção?
Resposta forte: primeiro, por excesso de dados: rede e memória são gastas em colunas de que você não precisa, e o banco perde a chance de responder só pelo índice (index-only scan; índices são o Capítulo 10). Segundo, por fragilidade: adicionar ou renomear colunas pode quebrar relatórios e códigos que dependem do conjunto e da ordem das colunas. Uma lista explícita de colunas é o contrato da consulta; SELECT * só é aceitável, no máximo, na exploração interativa de dados.
SELECT name FROM products WHERE category = 'Книги' vai mostrar?The index has been read: you know what’s in the five tables and which threads stitch them together. QUERY dims the map, and the next clearance level lights up on the holopanel — the reading terminal.
QUERY: Remember the cardinal property of this place: the archive answers only well-formed questions. From the next clearance on, we learn to ask precisely.