En trinnvis veiledning for å lese og forstå SQL-spørringer - KDnuggets

Publisert av Platon

Følgere: 0

En trinnvis veiledning for å lese og forstå SQL-spørringer
Bilde av Freepik

SQL, eller Standard Query Language, er et programmeringsspråk for å administrere og manipulere data i et relasjonsdatabasestyringssystem (RDBMS). Det er et standardspråk som brukes i mange selskaper for å hjelpe bedrifter med å få tilgang til data jevnt. Fordi det er mye brukt, siterer ansettelsen vanligvis SQL som en av de nødvendige ferdighetene. Det er derfor det er viktig å lære om SQL.

Et av de vanlige problemene for folk når de lærer SQL er å forstå spørringene, hovedsakelig når en annen person skriver dem. Vi vil jobbe som et team i selskapene og trenger ofte å lese og forstå SQL-spørsmålene deres. Så vi må øve på å dekonstruere SQL-spørringene og forstå dem.

Denne artikkelen vil gå gjennom en trinn-for-trinn-prosess for å lese og forstå SQL-spørringer. Hvordan gjør vi det? La oss komme inn i det.

Det første vi må gjøre når vi møter en SQL-spørring er å forstå den generelle intensjonen med SQL-spørringene. Den generelle intensjonen betyr ikke at vi vet helt om spørringens struktur; det handler mer om de generelle flytene.

Vi bør forstå standard SQL-spørringer for å forstå den generelle SQL-spørringen. De fleste SQL-spørringer starter med VELG klausul og følg med FRA klausul. Fortsetter derfra, blir forespørslene oftest fulgt av BLI, HVOR, GRUPPE AV, REKKEFØLGE ETTER, og HAR klausuler.

Klausulene ovenfor er standard i SQL-spørringene vi trenger å forstå. For hver klausul er funksjonene deres:

VELG: Hvilke kolonner skal tas fra tabellen
FRA: Hvilken tabell dataene kom fra
BLI: Kombiner tabeller med den angitte identifikatoren
HVOR: Datafilter basert på tilstanden
GRUPPE AV: Organiser dataene basert på kolonnens verdi og la aggregeringsfunksjonen utføres.
REKKEFØLGE ETTER: Ordne dataresultatrekkefølgen basert på den spesifikke kolonnen
HAR: Filterbetingelsen for aggregeringsfunksjon som ikke kan spesifiseres med HVOR

Dette er standardklausulene og hva du bør finne i begynnelsen når du forstår den generelle SQL-spørringsstrukturen. La oss bruke eksempelkoden for å lære videre.

SELECT 
  customers.name, 
  purchases.product, 
  SUM(price) as total_price 
FROM 
  purchases 
  JOIN customers ON purchases.cust_id = customers.id 
WHERE 
  purchases.category = 'kitchen' 
GROUP BY 
  customers.name, 
  purchases.product 
HAVING 
  total_price > 10000 
ORDER BY 
  total_price DESC;

Når du ser på spørringen ovenfor, prøv å identifisere standardklausulene. Klausulen vil gi deg en forståelse av hvilke data som er valgt (VELG), hvor det er fra (FRA og BLI), og tilstanden (HVOR, GRUPPE AV, REKKEFØLGE ETTERog HAR).

For eksempel vil lesing av spørringen ovenfor gi deg forståelse av følgende:

vi prøver å få tre forskjellige typer data: Navnet fra en tabell kalt kunder, Produktet fra en tabell kalt kjøp, og aggregeringen av priskolonner som ikke identifiserer hvor tabellen er fra og med aliaset total_price (Informasjon fra klausul VELG).

De overordnede dataene vil komme fra kjøps- og kundetabeller som slås sammen ved å bruke cust_id-kolonnen fra kjøp og id-kolonnen fra kundens tabell (Informasjon fra klausul FRA) og BLI).

Vi ville bare velge data med kategorikolonneverdien i kjøpstabellen som "kjøkken" (Informasjon fra klausul HVOR),

gruppe for aggregeringsfunksjonen med navn og produktkolonnen som kom fra den respektive tabellen (Informasjon fra klausul GRUPPE AV),

filtrert også fra aggregeringsfunksjonens resultatsum der total_price er mer enn 10000 (informasjon fra klausul HAR), Og

bestill dataene synkende i henhold til total_price (informasjon fra klausul REKKEFØLGE ETTER).

Det er den generelle SQL-spørringsstrukturen du trenger å kjenne til og identifisere. Derfra kan vi utforske videre fra den avanserte spørringen. La oss fortsette med neste trinn.

Det ville være en tid da du ville møte et komplekst spørsmål der så mange VELG klausuler finnes i samme spørring. I dette tilfellet bør vi forstå det endelige resultatet av spørringen eller det endelige (første) VELG du ser i spørringen. Nøkkelen er å vite hva spørringsutgangen vil være.

La oss bruke en mer kompleks kode som den nedenfor.

WITH customerspending AS (
  SELECT 
    customers.id, 
    SUM(purchases.price) as total_spending 
  FROM 
    purchases 
    JOIN customers ON purchases.cust_id = customers.id 
  GROUP BY 
    customers.id
) 
SELECT 
  c.name, 
  pd.product, 
  pd.total_product_price, 
  cs.total_spending 
FROM 
  (
    SELECT 
      purchases.cust_id, 
      purchases.product, 
      SUM(purchases.price) as total_product_price 
    FROM 
      purchases 
    WHERE 
      purchases.category = 'kitchen' 
    GROUP BY 
      purchases.cust_id, 
      purchases.product 
    HAVING 
      SUM(purchases.price) > 10000
  ) AS pd 
  JOIN customers c ON pd.cust_id = c.id 
  JOIN customerspending cs ON c.id = cs.id 
ORDER BY 
  pd.total_product_price DESC;

Spørringen virker mer kompleks og lengre nå, men det første fokuset bør være på den endelige PLUKKE UT, som ser ut til å prøve å produsere kundens totale forbruk og kjøpshistorikk. Prøv å vurdere hva det endelige resultatet vil være og bryte det ned derfra.

Vi har innsikt i resultatet skal være fra spørringene. Neste del er å se hvilke betingelser for finalen VELG er. Vilkårsparagrafen, inkludert HVOR, GRUPPE AV, REKKEFØLGE ETTERog HAR var de som kontrollerte det samlede dataresultatet.

Prøv å lese og forstå vilkårene for søket vårt, og vi vil bedre forstå søkets sluttresultat. For eksempel, i vår forrige SQL-spørring, er den endelige betingelsen bare REKKEFØLGE ETTER. Dette betyr at det endelige resultatet vil bli sortert etter den totale produktprisen i synkende rekkefølge.

Å kjenne de endelige betingelsene vil hjelpe deg med å forstå en betydelig del av søket og den generelle intensjonen.

Til slutt må vi forstå hvor dataene kommer fra. Etter at vi vet om dataene som skal velges og betingelsene for å få dem, må vi forstå kilden. Finalen BLI klausul vil gi oss en forståelse av hvordan tabellene samhandler og dataflyten.

For eksempel viser den forrige komplekse spørringen at vi utførte Join to ganger. Det betyr at vi brukte minst tre datakilder for det endelige resultatet. Denne informasjonen vil være nødvendig i de senere trinnene for å forstå ytterligere hvordan hver datakilde kommer, spesielt når datakilden kommer fra underspørringen.

Etter å ha forstått hvordan det endelige resultatet skal være og hvor det kommer fra, må vi se nærmere på detaljene. Herfra ville vi gå tilbake til hver underspørring og forstå hvorfor de er strukturert slik.

Vi prøver imidlertid ikke å se på dem i ovenfra-ned-strukturene. I stedet bør vi prøve å se på underspørringene som er nærmere sluttresultatet, og vi går opp til den som er lengst unna det endelige resultatet. Fra kodeeksemplet ovenfor bør vi prøve å forstå denne koden først:

SELECT 
  purchases.cust_id, 
  purchases.product, 
  SUM(purchases.price) as total_product_price 
FROM 
  purchases 
WHERE 
  purchases.category = 'kitchen' 
GROUP BY 
  purchases.cust_id, 
  purchases.product 
HAVING 
  SUM(purchases.price) > 10000

Deretter går vi til den lengste koden, som er denne:

WITH customerspending AS (
  SELECT 
    customers.id, 
    SUM(purchases.price) as total_spending 
  FROM 
    purchases 
    JOIN customers ON purchases.cust_id = customers.id 
  GROUP BY 
    customers.id
)

Vi kan spore opp forfatterens tankeprosess tydelig når vi bryter ned hver delspørring fra den som er nærmere resultatet til den lengste.

Prøv å gjenta prosessen ovenfor hvis du trenger hjelp til å forstå hver delspørring. Med litt trening vil du få en bedre opplevelse av å lese og forstå spørringen.

Å lese og forstå SQL-spørringer er en ferdighet som alle burde ha i moderne tid, ettersom alle bedrifter håndterer dem. Ved å bruke den følgende trinnvise veiledningen vil du ha bedre tid til å forstå de komplekse SQL-spørringene. Trinnene inkluderer:

Forstå den generelle SQL-spørringsstrukturen
Forstå det endelige valget
Forstå den endelige vilkårsklausulen
Forstå Final Join
Lesing og gjenta omvendt rekkefølge

Cornellius Yudha Wijaya er assistentleder for datavitenskap og dataskribent. Mens han jobber på heltid i Allianz Indonesia, elsker han å dele Python- og Data-tips via sosiale medier og skrivemedier.