Pierwsze użyteczne zapytanie
What you'll learn
- pisać zapytania z jawną listą kolumn po
SELECTi filtrem wierszy przezWHERE - przekładać pytanie biznesowe na SQL według schematu: encja →
FROM, ograniczenia →WHERE(zAND), wynik →SELECT, porządek →ORDER BY - wyjaśniać, dlaczego
SELECT *to zła praktyka w roboczych zapytaniach - sprawdzać zapytanie, opowiadając je na głos: jeśli opowieść zgadza się z pierwotnym pytaniem, zapytanie jest poprawne co do sensu
Mapa poznana — i QUERY zmienia reguły. Dotąd przyglądałeś się archiwum w całości, jak turysta; archiwista pracuje inaczej. Na holopanelu gaśnie wszystko poza jedną tabelą i pojawia się zadanie: zadaj pytanie tak, żeby w odpowiedzi nie znalazł się ani jeden zbędny wiersz i ani jedna zbędna kolumna.
Wybieramy potrzebne kolumny i wiersze
Pobieranie wszystkiego przez * jest wygodne przy pierwszym rozpoznaniu, ale w prawdziwej pracy przypomina przyniesienie do kasy całego magazynu. Zwykle potrzebujesz konkretnych pól: wymień je po przecinku po SELECT.
Z wierszami jest tak samo: zamiast całej wystawy wybierz tylko potrzebny segment przez WHERE. Na przykład poprośmy „Kotomarket” tylko o towary z kategorii Książki:
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 |
Z pytania biznesowego — w zapytanie
Prawdziwe pytania nie przychodzą do archiwisty w SQL: „które książki są tańsze niż półtora tysiąca?”, „co z elektroniki kosztuje więcej niż 5000?”. Przekład zawsze przebiega podobnie:
- Encja → tabela. O czym jest pytanie: o towarach, kupujących, zamówieniach? „Książki tańsze niż 1500” — o towarach, czyli
FROM products. - Ograniczenia → WHERE. Każdy warunek z pytania to osobny warunek filtra: kategoria „Książki”, cena mniejsza niż 1500.
- Co pokazać → SELECT. Co człowiek chce zobaczyć w odpowiedzi? Nazwę i cenę — je właśnie wymieniamy, reszta to szum.
- Forma odpowiedzi → ORDER BY. „Od tanich do drogich” — sortowanie po cenie.
-- „Które książki są tańsze niż 1500 i ile kosztują, od tanich do drogich?”
SELECT name, price
FROM products
WHERE category = 'Книги' AND price < 1500
ORDER BY price;
Kilka warunków łączy się słowem AND — operatory filtrowania omówimy szczegółowo w następnym rozdziale.
Drugi dobry nawyk archiwisty: przeczytaj gotowe zapytanie na głos jak zdanie. „Z towarów weź książki tańsze niż 1500, pokaż nazwę i cenę, posortuj po cenie” — jeśli opowieść zgadza się z pierwotnym pytaniem, zapytanie jest poprawne co do sensu. Jeśli w opowieści wypłynęło „wszystkie kolumny” albo „cała wystawa” — wróć i zawęź.
Interview question
Pytanie z rozmowy kwalifikacyjnej: dlaczego SELECT * uchodzi za złą praktykę w roboczych zapytaniach?
Mocna odpowiedź: po pierwsze, zbędne dane: marnujesz sieć i pamięć na kolumny, które nie są potrzebne, a baza może stracić szansę na odpowiedź tylko po indeksie (index-only scan; indeksy — Rozdział 10). Po drugie, kruchość: gdy ktoś doda kolumnę albo zmieni nazwy, raporty i kod, które liczą na konkretny skład oraz kolejność kolumn, mogą się złamać. Jawna lista kolumn to kontrakt zapytania; SELECT * ma sens właściwie tylko przy interaktywnym badaniu danych.
SELECT name FROM products WHERE category = 'Книги'?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.