SQL — fra SELECT til triggere
Det praktiske språket man faktisk bruker. Fire forelesninger, fire deler — fra grunnleggende spørringer til prosedyrer og rekursjon.
SQL er flere språk i ett
SQL ble utviklet av IBM tidlig på 1970-tallet som Sequel, en del av System R-prosjektet, og standardisert av ANSI/ISO i 1986. I dag er det det udiskutable standardspråket for relasjonsdatabaser. Men SQL er ikke ett språk — det er en familie underspråk som dekker alt fra å definere skjemaer til å gi rettigheter til brukere.
Kjenner du dimensjonene under, blir det mye lettere å forstå hvor i SQL en gitt kommando hører hjemme:
SQL er deklarativt: du sier hva du vil ha, ikke hvordan det skal hentes. Optimalisatoren oversetter SELECT … FROM … WHERE … til en eksekverbar plan basert på indekser, statistikk og kostnadsmodeller. Vi lærer SQL i kap. 3, men optimaliseringen ligger i kap. 7.
ALTER TABLE … ADD COLUMN … endrer strukturen (skjemaet) til relasjonen, ikke radene. Det er DDL-territorium.Hjertet i SQL: SELECT … FROM … WHERE …
Selv om mye av kapitlet handler om DDL, integritet og prosedyrer, er det SELECT-spørringen du møter mest. Den har tre obligatoriske komponenter pluss flere valgfrie. Husk: SQL skrives i én rekkefølge, men evalueres i en helt annen.
WHERE ikke kan referere til en kolonnealias fra SELECT).Fordi SELECT evalueres etter WHERE, kan du ikke bruke en kolonnealias definert i SELECT i en WHERE-betingelse på samme spørringsnivå. Dette er en hyppig eksamensspørsmål-felle.
WHERE evalueres før SELECT, så aliaset hike finnes ikke ennå. ORDER BY evalueres derimot etter SELECT og kan trygt bruke aliaser.Utforsk kapittelet
Hver delside dekker én forelesning og bygger på den foregående. Ta dem i rekkefølge første gang.
SQL-syntaks for transaksjoner (BEGIN/COMMIT/ROLLBACK) introduseres i del 3C, men teorien bak — ACID, isolasjon, samtidighet, recovery — hører hjemme i kapittel 8.
Når du er ferdig med kap. 3 skal du …
Konsept-quiz
Tolv flervalgsspørsmål på tvers av hele kapitlet. Detaljerte spørsmål per tema finner du på hver delside.
DELETE FROM r; fjerner alle rader, men beholder definisjonen. DROP TABLE ville slettet selve tabellen.SELECT COUNT(*) og SELECT COUNT(salary) kan gi forskjellige svar fordi …COUNT(*)) ignorerer NULL.WHERE x = NULL returnerer aldri rader. Hva er den rette forklaringen?x IS NULL for å sjekke om x mangler.WHERE x IN (SELECT y FROM t) selv når y kan være NULL?= ANY er teoretisk ekvivalent, men EXISTS er mest robust. Den klassiske fellen er NOT IN — den feiler stille om subqueryen returnerer minst én NULL.CREATE VIEW v AS SELECT a, b FROM t WHERE c > 0 er ikke oppdaterbar via INSERT hvis …ON DELETE CASCADE i en foreign key-deklarasjon?Klar for mer fordypning? Hopp til 3A — DDL og spørringer.