{
  "assessmentTests": {
    "sql_test": {
      "name": "SQL-test",
      "desc": "30 scenariospørsmål om filtrering, joiner, aggregering, underspørringer og vindusfunksjoner — finn ut om din SQL-kunskap matcher det som jobbutlysninger forventer av SQL-kompetanse.",
      "recommendation": "Din SQL-ferdighetsprofil",
      "results": {
        "beginner": {
          "name": "Nybegynner",
          "desc": "Du kan skrive en fungerende SELECT-setning og filtrere på noen få betingelser, men spørsmålene du bommet på handler først og fremst om NULL-håndtering og join-mekanikk snarere enn syntaks — sammenligning av en kolonne mot NULL med =, hva LEFT JOIN egentlig bevarer, hvordan BETWEEN-grensene fungerer. Ingen av dette handler om å være dårlig med databaser; disse er de spesifikke reglene som forvirrer folk som har lært SQL gjennom prøving og feiling snarere enn fra standarden. De betyr noe på jobben fordi hver regel er der en spørring returnerer en sannsynlig-men-gal radtelling.",
          "recommendation": "Start med tre ting, i denne rekkefølgen: hvorfor WHERE col = NULL aldri matcher noe (og IS NULL kreves i stedet), hvordan INNER JOIN dropper uovertruffen rader mens LEFT JOIN beholder dem, og de eksakte grensene BETWEEN inkluderer. Mode Analytics' SQL-veiledning og PostgreSQL-dokumentasjonen dekker alle tre med kjørbare eksempler."
        },
        "intermediate": {
          "name": "Intermediær",
          "desc": "Du håndterer hverdagslige rapporteringsspørringer komfortabelt — joiner, GROUP BY, enkel filtrering — og ville ikke blitt forsinket av rutinedashboard- eller ad-hoc-analysearbeid. Gapet mellom her og Avansert handler først og fremst om hva som skjer når klausuler samhandler: en WHERE-klausul på den joinede tabellen som stille gjør en LEFT JOIN til en INNER JOIN, en join som spruter ut radsett før en aggregering brukes på dem, en NOT IN som stille returnerer ingenting fordi en NULL sneket seg inn i underspørringen. Det er den slags feil som passerer en rask visuell sjekk og bare dukker opp når noen sammenligner totalen med en annen rapport.",
          "recommendation": "Fokuser på hvordan klausuler samhandler snarere enn hva hver enkelt gjør alene: WHERE-filtrering på en LEFT JOINs høyre-side-kolonner, radmultiplikasjon fra en-til-mange-joiner før du aggregerer, og hvorfor NOT IN bryter når NULLer er involvert (EXISTS gjør det vanligvis ikke). Deretter HAVING vs WHERE, siden det skillet forvirrer folk som allerede kjenner begge klausulene hver for seg."
        },
        "advanced": {
          "name": "Avansert",
          "desc": "Dette er nivået de fleste jobbutlysninger mener med «sterk SQL.» Du leser en multi-join-spørring og kan forutsi dens radtelling før du kjører den, du vet hvorfor et resultatett endret seg snarere enn bare at det gjorde det, og du griper til en CTE eller en vindusfunksjon i stedet for en nestet underspørring når det er det klarere verktøyet. Hva skiller dette bandet fra toppen er den defensive siden av arbeidet: å vite hvilken rangerfunksjon som skal brukes når uavgjort betyr noe, hva en transaksjon isolerer fra en samtidig sesjon, og hva en manglende ON DELETE-regel faktisk gjør på databasenivå.",
          "recommendation": "Dyp dykk inn i delene som beskytter data andre mennesker også rører: forskjellen mellom RANK, DENSE_RANK og ROW_NUMBER under uavgjort, hva COMMIT faktisk gjør synlig og for hvem, og oppførsel av fremmednøkkel ved DELETE. Bruk The Index-nyhetsbrevet eller SQL for Devs' dyptgående dykk på vindusfunksjoner og transaksjonisolering som neste stopp for begge."
        },
        "expert": {
          "name": "Ekspert",
          "desc": "Du scoret på toppen av hver seksjon — filtrering og NULL-semantikk, joiner og set-operasjoner, aggregering og underspørringer, og vindusfunksjoner, CTEer og constraints. Praktisk sett betyr det at du kan få en fremmed multi-join-rapportspørring overlevert og forklare hvorfor den returnerer radsummen den gjør, ikke bare hva syntaksen sier at den burde gjøre, som er den vanskeligere og mer verdifulle ferdigheten. På dette nivået er spørringsspråket sjelden en begrensningsfaktor; grensen er vanligvis skjemadesign eller størrelsen på dataene under det.",
          "recommendation": "Avkastningen er nå i kjøreplaner og design: lesing av EXPLAIN-utdata før du antar at en spørring er treg, indekseringsstrategi som en avveining mot skrivekostnad snarere enn en fri seier, og normaliseringsbeslutninger som holder seg når et skjema vokser. Hvis du blir screenet for en rolle, beskriv en spørringsfeil som du fant i produksjon, for eksempel join-spruting eller NOT IN/NULL-fellen, snarere enn å nevne SQL-funksjoner — det demonstrerer resonnementet, ikke bare ordforrådet."
        }
      },
      "questions": [
        {
          "question": "En tabell har en nullable kolonne age. Du kjører SELECT * FROM users WHERE age = NULL. Hvor mange rader returnerer den, selv om flere rader har age satt til NULL?",
          "options": [
            {
              "icon": "",
              "label": "Hver rad der age er NULL, fordi = matcher NULL som andre verdier"
            },
            {
              "icon": "",
              "label": "Null — sammenligning av noe med NULL ved bruk av = produserer UNKNOWN, aldri TRUE, så ingen rader matcher; IS NULL kreves i stedet"
            },
            {
              "icon": "",
              "label": "En syntaksfeil — NULL kan ikke vises på høyre side av ="
            },
            {
              "icon": "",
              "label": "Hver rad i tabellen, fordi NULL-sammenligninger standarder til TRUE"
            }
          ]
        },
        {
          "question": "Du kjører SELECT DISTINCT department, role FROM employees. Hva fjerner DISTINCT duplikater av?",
          "options": [
            {
              "icon": "",
              "label": "Kombinasjonen av department og role sammen — en rad fjernes bare hvis begge kolonner matcher en annen rad nøyaktig"
            },
            {
              "icon": "",
              "label": "Bare dupliserte department-verdier, beholder alle roller"
            },
            {
              "icon": "",
              "label": "Bare dupliserte role-verdier, beholder hver avdeling"
            },
            {
              "icon": "",
              "label": "Ingenting — DISTINCT fungerer bare med en enkelt kolonne"
            }
          ]
        },
        {
          "question": "En kolonne name filtreres med WHERE name LIKE 'A_'. Hvilke av disse verdiene matcher: 'A', 'Al', 'Ana', 'Ally'?",
          "options": [
            {
              "icon": "",
              "label": "'A' — understrekingen er valgfri og matcher null eller flere tegn"
            },
            {
              "icon": "",
              "label": "'Al' — understrekingen matcher nøyaktig ett tegn, så LIKE 'A_' matcher en hvilken som helst to-tegns streng som starter med A"
            },
            {
              "icon": "",
              "label": "'Ana' og 'Ally' — understrekingen matcher et hvilket som helst antall etterfølgende tegn"
            },
            {
              "icon": "",
              "label": "Alle fire verdier matcher, fordi LIKE ignorerer lengde"
            }
          ]
        },
        {
          "question": "En price-kolonne filtreres med WHERE price BETWEEN 10 AND 20. Inkluderes rader med price nøyaktig 10 eller nøyaktig 20?",
          "options": [
            {
              "icon": "",
              "label": "Nei — BETWEEN ekskluderer begge endepunktene"
            },
            {
              "icon": "",
              "label": "Ja — BETWEEN er inklusiv på begge ender, ekvivalent med price >= 10 AND price <= 20"
            },
            {
              "icon": "",
              "label": "Bare price = 10 er inkludert; den øvre grensen er eksklusiv"
            },
            {
              "icon": "",
              "label": "Bare price = 20 er inkludert; den nedre grensen er eksklusiv"
            }
          ]
        },
        {
          "question": "En tabell orders har 10 rader, og 3 av dem har en NULL shipped_date. Hva returnerer SELECT COUNT(*) FROM orders, og hva returnerer SELECT COUNT(shipped_date) FROM orders?",
          "options": [
            {
              "icon": "",
              "label": "10, så 10 — COUNT teller alltid rader uavhengig av NULLer"
            },
            {
              "icon": "",
              "label": "7, så 7 — begge former hopper over NULL-rader"
            },
            {
              "icon": "",
              "label": "10, så 7 — COUNT(*) teller hver rad, COUNT(kolonne) teller bare rader der denne kolonnen ikke er NULL"
            },
            {
              "icon": "",
              "label": "10, så 3 — COUNT(kolonne) teller bare NULL-verdiene"
            }
          ]
        },
        {
          "question": "Du kjører SELECT name, salary FROM employees ORDER BY 2 DESC. Hva refererer 2 til?",
          "options": [
            {
              "icon": "",
              "label": "En syntaksfeil — ORDER BY godtar bare kolonnenavn, ikke tall"
            },
            {
              "icon": "",
              "label": "Den andre raden av resultatet"
            },
            {
              "icon": "",
              "label": "En bokstavelig verdi av 2, brukt som en tiebreaker"
            },
            {
              "icon": "",
              "label": "Den andre kolonnen i SELECT-listen, salary — ORDER BY godtar en kolonnes posisjonnummer som shorthand"
            }
          ]
        },
        {
          "question": "I standard SQL, hva evaluerer 'Ana' || ' ' || 'Lee' til?",
          "options": [
            {
              "icon": "",
              "label": "En syntaksfeil — SQL har ingen konkatenjeringsoperator"
            },
            {
              "icon": "",
              "label": "3 — || behandles som en boolsk OR og returnerer en telling"
            },
            {
              "icon": "",
              "label": "'AnaLee' — || konkatenerer uten å bevare mellomrom"
            },
            {
              "icon": "",
              "label": "'Ana Lee' — || er standard SQL-streng-konkatenjeringsoperatøren"
            }
          ]
        },
        {
          "question": "Hvilken av disse er nøyaktig ekvivalent med WHERE status IN ('open', 'pending', 'review')?",
          "options": [
            {
              "icon": "",
              "label": "WHERE status = 'open' AND status = 'pending' AND status = 'review'"
            },
            {
              "icon": "",
              "label": "WHERE status != 'open' OR status != 'pending' OR status != 'review'"
            },
            {
              "icon": "",
              "label": "WHERE status = 'open' OR status = 'pending' OR status = 'review'"
            },
            {
              "icon": "",
              "label": "WHERE status LIKE 'open,pending,review'"
            }
          ]
        },
        {
          "question": "customers har 100 rader; 20 av dem har aldri lagt inn en ordre. Du kjører SELECT c.id FROM customers c INNER JOIN orders o ON c.id = o.customer_id. Dukker de 20 kundene uten ordrer opp i resultatet?",
          "options": [
            {
              "icon": "",
              "label": "Ja, en gang hver, med o.id vist som NULL"
            },
            {
              "icon": "",
              "label": "Ja, men bare hvis de også vises i en WHERE-klausul"
            },
            {
              "icon": "",
              "label": "Nei — INNER JOIN returnerer bare rader som har samsvar i begge tabeller, så kunder uten ordrer blir droppet helt"
            },
            {
              "icon": "",
              "label": "Ja, duplisert en gang per kolonne i orders"
            }
          ]
        },
        {
          "question": "Du vil ha hver kunde enten de har ordrer eller ikke, så du skriver SELECT c.id, o.total FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.total > 100. Returnerer dette kunder uten ordrer?",
          "options": [
            {
              "icon": "",
              "label": "Nei — filtrering på o.total i WHERE-klausulen forkaster NULL-radene som LEFT JOIN produserte for uovertruffen kunder, så det oppfører seg som en INNER JOIN"
            },
            {
              "icon": "",
              "label": "Ja — LEFT JOIN bevarer alltid hver rad fra customers uansett hva som følger"
            },
            {
              "icon": "",
              "label": "Ja, med o.total vist som 0 for kunder uten ordrer"
            },
            {
              "icon": "",
              "label": "Nei — LEFT JOIN konverterer seg stille til en RIGHT JOIN når en WHERE-klausul legges til"
            }
          ]
        },
        {
          "question": "En employees-tabell har en id-kolonne og en manager_id-kolonne som peker til en annen rads id. For å liste hver ansatt ved siden av sin leders navn, joinerer du tabellen til seg selv: SELECT e.name, m.name FROM employees e JOIN employees m ON e.manager_id = m.id. Hva kalles dette mønsteret?",
          "options": [
            {
              "icon": "",
              "label": "En cross join — hver ansatt matches med hver leder"
            },
            {
              "icon": "",
              "label": "En rekursiv join — den henter hele ledelseskjeden"
            },
            {
              "icon": "",
              "label": "En self-join — samme tabell joineres til seg selv ved bruk av to ulike aliaser"
            },
            {
              "icon": "",
              "label": "Dette er ugyldig SQL — en tabell kan ikke joineres til seg selv"
            }
          ]
        },
        {
          "question": "To SELECT-spørringer med samme kolonner kombineres med UNION. Hvis begge spørringene returnerer en identisk rad, hvor mange kopier av denne raden vises i sluttresultatet?",
          "options": [
            {
              "icon": "",
              "label": "En — UNION fjerner dupliserte rader over det kombinerte resultatet; UNION ALL ville holdt begge kopier"
            },
            {
              "icon": "",
              "label": "To — UNION holder hver rad fra begge spørringene"
            },
            {
              "icon": "",
              "label": "Null — UNION fjerner enhver rad som vises i begge spørringene"
            },
            {
              "icon": "",
              "label": "Det avhenger av hvilken spørring som listet raden først"
            }
          ]
        },
        {
          "question": "Tabell sizes har 3 rader og colors har 4 rader. Hvor mange rader returnerer SELECT * FROM sizes CROSS JOIN colors?",
          "options": [
            {
              "icon": "",
              "label": "7 — CROSS JOIN legger til radtallene"
            },
            {
              "icon": "",
              "label": "12 — en CROSS JOIN returnerer hver mulig kombinasjon av rader fra begge tabeller (3 x 4)"
            },
            {
              "icon": "",
              "label": "3 — CROSS JOIN returnerer en rad per rad i den første tabellen"
            },
            {
              "icon": "",
              "label": "0 — CROSS JOIN krever en ON-betingelse eller returnerer ingenting"
            }
          ]
        },
        {
          "question": "orders har 1 rad for ordre #100, og order_items har 3 rader for ordre #100 (en per linjeelement). Du kjører SELECT o.id, o.total FROM orders o JOIN order_items i ON o.id = i.order_id WHERE o.id = 100. Hvor mange rader kommer tilbake for ordre #100?",
          "options": [
            {
              "icon": "",
              "label": "3 — joinen produserer en utrad per matchende order_items-rad, så ordre #100s enkelte rad gjentas en gang per linjeelement"
            },
            {
              "icon": "",
              "label": "1 — orders har bare en rad for ordre #100, så joinen kan ikke produsere mer"
            },
            {
              "icon": "",
              "label": "4 — en rad for ordren pluss en per linjeelement"
            },
            {
              "icon": "",
              "label": "0 — å joine en en-rad-tabell til en tre-rad-tabell på en ikke-unik nøkkel mislykkes"
            }
          ]
        },
        {
          "question": "SELECT c.name, o.id FROM customers c RIGHT JOIN orders o ON c.id = o.customer_id returnerer samme rader som hvilken av disse?",
          "options": [
            {
              "icon": "",
              "label": "SELECT c.name, o.id FROM customers c INNER JOIN orders o ON c.id = o.customer_id"
            },
            {
              "icon": "",
              "label": "SELECT c.name, o.id FROM orders o LEFT JOIN customers c ON c.id = o.customer_id — å bytte tabelrekkefølge og bruke LEFT JOIN i stedet for RIGHT JOIN er ekvivalent"
            },
            {
              "icon": "",
              "label": "SELECT c.name, o.id FROM customers c LEFT JOIN orders o ON c.id = o.customer_id"
            },
            {
              "icon": "",
              "label": "SELECT c.name, o.id FROM orders o CROSS JOIN customers c"
            }
          ]
        },
        {
          "question": "I standard SQL, kjører du SELECT department, name, AVG(salary) FROM employees GROUP BY department. Er dette en gyldig spørring?",
          "options": [
            {
              "icon": "",
              "label": "Ja — GROUP BY trenger bare å inkludere department fordi det er oppført først"
            },
            {
              "icon": "",
              "label": "Nei — name er valgt men verken aggregert eller oppført i GROUP BY, og standard SQL krever at hver ikke-aggregert valgt kolonne vises i GROUP BY-klausulen"
            },
            {
              "icon": "",
              "label": "Ja — SQL velger automatisk ett vilkårlig navn per avdeling"
            },
            {
              "icon": "",
              "label": "Nei — AVG() kan ikke kombineres med GROUP BY i samme spørring"
            }
          ]
        },
        {
          "question": "Du vil ha avdelinger hvis gjennomsnittlige lønn overskrider 80000. Hvilken klausul filtrerer på en aggregert verdi som AVG(salary) etter gruppering — WHERE eller HAVING?",
          "options": [
            {
              "icon": "",
              "label": "WHERE — HAVING brukes bare med UNION-spørringer"
            },
            {
              "icon": "",
              "label": "Enten fungerer identisk med aggregatfunksjoner"
            },
            {
              "icon": "",
              "label": "Ingen — aggregatfiltrering krever en underspørring"
            },
            {
              "icon": "",
              "label": "HAVING — WHERE filtrerer individuelle rader før gruppering skjer, HAVING filtrerer grupper etter aggregering"
            }
          ]
        },
        {
          "question": "Du skriver SELECT salary * 1.1 AS new_salary FROM employees WHERE new_salary > 50000. Kjører dette?",
          "options": [
            {
              "icon": "",
              "label": "Ja — aliaser definert i SELECT er alltid tilgjengelige for WHERE i samme spørring"
            },
            {
              "icon": "",
              "label": "Ja, men bare for numeriske aliaser"
            },
            {
              "icon": "",
              "label": "Nei — AS er ikke tillatt inne i en WHERE-filtret spørring"
            },
            {
              "icon": "",
              "label": "Nei — WHERE evalueres før SELECT tildeler aliaset new_salary, så aliaset finnes ikke ennå på det tidspunktet i kjøringen"
            }
          ]
        },
        {
          "question": "SELECT name FROM employees e WHERE salary > (SELECT AVG(salary) FROM employees WHERE department = e.department). Hvorfor kalles dette en korrelert underspørring?",
          "options": [
            {
              "icon": "",
              "label": "Fordi det bruker en JOIN i stedet for WHERE-klausul"
            },
            {
              "icon": "",
              "label": "Den indre underspørringen refererer e.department fra den ytre spørringen, så den må re-evalueres for hver rad den ytre spørringen vurderer"
            },
            {
              "icon": "",
              "label": "Fordi den returnerer mer enn en kolonne"
            },
            {
              "icon": "",
              "label": "Fordi den kjøres nøyaktig en gang før den ytre spørringen starter"
            }
          ]
        },
        {
          "question": "En underspørring SELECT manager_id FROM employees returnerer noen NULL-verdier sammen med reelle IDer. Du kjører SELECT name FROM employees WHERE id NOT IN (SELECT manager_id FROM employees). Hva skjer?",
          "options": [
            {
              "icon": "",
              "label": "Den returnerer hver ansatt som ikke er en leder, ignorerer NULLene"
            },
            {
              "icon": "",
              "label": "Den returnerer null rader — en enkelt NULL i NOT IN-listen gjør hver sammenligning UNKNOWN, så ingen rad kan oppfylle betingelsen"
            },
            {
              "icon": "",
              "label": "Den kaster en feil fordi NOT IN ikke kan brukes med underspørringer"
            },
            {
              "icon": "",
              "label": "Den returnerer hver ansatt, siden NULL behandles som et jokertegn"
            }
          ]
        },
        {
          "question": "SELECT name FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id). Hva returnerer dette?",
          "options": [
            {
              "icon": "",
              "label": "Hver kunde som har minst en rad i orders — EXISTS sjekker bare om underspørringen returnerer noen rader, ikke hva verdiene inneholder"
            },
            {
              "icon": "",
              "label": "Hver kunde, fordi SELECT 1 alltid returnerer true"
            },
            {
              "icon": "",
              "label": "En feil, fordi underspørringen velger et tall i stedet for et kolonnenavn"
            },
            {
              "icon": "",
              "label": "Bare kunder med nøyaktig en ordre"
            }
          ]
        },
        {
          "question": "Du skriver SELECT name, (SELECT order_id FROM orders WHERE customer_id = c.id) AS last_order FROM customers c, og en gitt kunde har 3 rader i orders. Hva skjer når denne spørringen kjøres?",
          "options": [
            {
              "icon": "",
              "label": "Den returnerer den første matchende order_id og ignorerer stille de andre to"
            },
            {
              "icon": "",
              "label": "Den returnerer en kommaseparert liste over alle tre order_id-ene"
            },
            {
              "icon": "",
              "label": "Den returnerer 3 rader for den kunden, en per ordre"
            },
            {
              "icon": "",
              "label": "Den kaster en feil under kjøring — en skalar-underspørring i SELECT-listen må returnere maksimalt en rad, og denne returnerer tre"
            }
          ]
        },
        {
          "question": "Fire rader binder for den høyeste poengsum. Ved bruk av RANK() ORDER BY score DESC får alle fire rank 1. Hvilken rank får neste rad ned?",
          "options": [
            {
              "icon": "",
              "label": "5 — RANK() etterlater et gap lik antallet bundne rader før fortsettelse"
            },
            {
              "icon": "",
              "label": "2 — RANK() øker alltid med nøyaktig en etter en binding"
            },
            {
              "icon": "",
              "label": "1 — hver etterfølgende rad får også rank 1"
            },
            {
              "icon": "",
              "label": "4 — RANK() starter tellingen på nytt fra antallet bindinger"
            }
          ]
        },
        {
          "question": "Fire rader binder for den høyeste poengsum. Ved bruk av DENSE_RANK() ORDER BY score DESC får alle fire rank 1. Hvilken rank får neste rad ned?",
          "options": [
            {
              "icon": "",
              "label": "5 — DENSE_RANK() oppfører seg nøyaktig som RANK()"
            },
            {
              "icon": "",
              "label": "1 — DENSE_RANK() tildeler samme rank til hver gjenværende rad"
            },
            {
              "icon": "",
              "label": "2 — DENSE_RANK() etterlater aldri gap, så neste distinkte verdi får alltid neste påfølgende rank"
            },
            {
              "icon": "",
              "label": "3 — DENSE_RANK() hopper over en rank per bindingsgruppe"
            }
          ]
        },
        {
          "question": "SUM(amount) OVER (PARTITION BY region ORDER BY amount) legges til en spørring. Hva gjør PARTITION BY region her?",
          "options": [
            {
              "icon": "",
              "label": "Den starter den løpende summen på nytt separat for hver region, i stedet for akkumulering over hele resultatsettet"
            },
            {
              "icon": "",
              "label": "Den filtrerer resultatene til en enkelt region"
            },
            {
              "icon": "",
              "label": "Den grupperer og kollapser radene til en per region, som GROUP BY"
            },
            {
              "icon": "",
              "label": "Den sorterer regionene alfabetisk før summering"
            }
          ]
        },
        {
          "question": "ROW_NUMBER() OVER (ORDER BY score DESC) brukes på fem rader, to av disse som er nøyaktig bundet i poengsum. Kan to rader noen gang motta samme radnummer?",
          "options": [
            {
              "icon": "",
              "label": "Ja — bundne rader deler alltid samme radnummer"
            },
            {
              "icon": "",
              "label": "Bare hvis PARTITION BY også brukes"
            },
            {
              "icon": "",
              "label": "Det avhenger av om bindingen er i første eller siste posisjon"
            },
            {
              "icon": "",
              "label": "Nei — ROW_NUMBER() tildeler alltid et unikt, strengt økende heltall til hver rad, selv når verdier er bundet"
            }
          ]
        },
        {
          "question": "WITH high_earners AS (SELECT * FROM employees WHERE salary > 100000) SELECT department, COUNT(*) FROM high_earners GROUP BY department. Hva er high_earners?",
          "options": [
            {
              "icon": "",
              "label": "Et felles tabeluttrykk (CTE) — et navngitt, midlertidig resultatset som resten av spørringen kan referere som en tabell"
            },
            {
              "icon": "",
              "label": "En permanent tabell opprettet i databasen"
            },
            {
              "icon": "",
              "label": "En visning som vedvarer etter at spørringen er ferdig"
            },
            {
              "icon": "",
              "label": "En lagret prosedyre som må kalles separat"
            }
          ]
        },
        {
          "question": "En kolonne er erklært PRIMARY KEY. Kan du sette inn en rad der denne kolonnen er NULL?",
          "options": [
            {
              "icon": "",
              "label": "Ja — PRIMARY KEY håndhever bare unikalitet, ikke NULL-ness"
            },
            {
              "icon": "",
              "label": "Ja, men bare en NULL-rad er tillatt, samme som en UNIQUE-constraint"
            },
            {
              "icon": "",
              "label": "Nei — en PRIMARY KEY-kolonne er implisitt NOT NULL, så innsetting av NULL i den blir avvist"
            },
            {
              "icon": "",
              "label": "Det avhenger av om kolonnen også har en standardverdi"
            }
          ]
        },
        {
          "question": "Inne i en åpen transaksjon kjører du en UPDATE men har ennå ikke kjørt COMMIT. Fra en annen, separat tilkobling til databasen, er denne oppdateringen synlig?",
          "options": [
            {
              "icon": "",
              "label": "Ja — alle tilkoblinger ser hver skrift det øyeblikket den kjøres"
            },
            {
              "icon": "",
              "label": "Ja, men bare hvis den andre tilkoblingen også åpner en transaksjon"
            },
            {
              "icon": "",
              "label": "Det avhenger bare av hvilken tabell som ble oppdatert"
            },
            {
              "icon": "",
              "label": "Nei — en uforpliktet endring er bare synlig inne i transaksjonen som gjorde den, inntil COMMIT gjør den varig og synlig for andre"
            }
          ]
        },
        {
          "question": "products.category_id har en FOREIGN KEY-constraint som refererer categories.id. Du prøver å DELETE en rad fra categories som fortsatt har produkter som peker på den, uten ON DELETE-regel spesifisert. Hva skjer?",
          "options": [
            {
              "icon": "",
              "label": "Kategorirade slettes og matchende products.category_id-verdier settes automatisk til NULL"
            },
            {
              "icon": "",
              "label": "Kategorirade slettes og hver produkt som refererte den slettes også"
            },
            {
              "icon": "",
              "label": "DELETE blir avvist — standard fremmednøkkel-oppførsel blokkerer sletting av en referert rad mens avhengige rader fortsatt peker på den"
            },
            {
              "icon": "",
              "label": "DELETE lykkes stille, og etterlater products' category_id som peker på en kategori som ikke lenger finnes"
            }
          ]
        }
      ],
      "optionOrderVersion": "e0466e547cfd8a45"
    }
  }
}