SQL SELECT: query's uitvoeren

Een query vraagt gegevens op uit een database. Een gewone SELECT-query leest de opgeslagen tabel zonder die te veranderen. SELECT geeft aan welke kolommen worden weergegeven en FROM welke tabel wordt gelezen.

De tekstvoorbeelden gebruiken gewone hoofdlettergevoelige gelijkheidsvergelijkingen in SQLite en PostgreSQL. Instellingen voor sorteerregels kunnen veranderen hoe tekst wordt vergeleken en gesorteerd.

Twee tabellen om mee te werken

De tabel employees bevat deze acht rijen. salary is het jaarsalaris in euro; hire_date is tekst in de vorm YYYY-MM-DD. NULL duidt een ontbrekende waarde aan.

De tabel products legt prijzen in euro en voorraad in magazijneenheden vast.

Lees de opbouw van de query

SELECT city, first_name
FROM employees;

De resultaatset is een andere tabel: acht rijen en twee kolommen, met city voorop. Er is geen filter, dus elke medewerker levert een rij op. SQL garandeert geen rijvolgorde totdat je ORDER BY toevoegt.

SELECT * FROM products; toont alle kolommen in de volgorde waarin ze in de tabel zijn gedefinieerd. De ster is handig om te verkennen. Als je in een opgeslagen query de kolommen bij naam noemt, blijft het resultaat gericht en verandert de vorm niet als een nieuwe kolom aan de tabel wordt toegevoegd.

Maak de syntaxis leesbaar

Scheid kolommen met komma's, zonder afsluitende komma vóór FROM. Sluit de instructie af met een puntkomma. Sleutelwoorden zijn niet hoofdlettergevoelig, dus select werkt, maar door hoofdletters zijn clausules makkelijk te vinden. Spaties en regeleinden scheiden woorden; ze veranderen de betekenis van deze query niet. Een commentaar met -- loopt door tot het einde van de regel.

Namen moeten overeenkomen met het schema. Als frist_name een foutmelding over een ontbrekende kolom veroorzaakt, vergelijk de spelling dan met first_name. Standaard-SQL gebruikt dubbele aanhalingstekens voor namen met spaties of gereserveerde woorden, zoals "order date". PostgreSQL zet namen zonder aanhalingstekens om naar kleine letters, terwijl "City" vraagt om die exacte naam met hoofdletter. MySQL gebruikt normaal gesproken backticks; dubbele aanhalingstekens duiden namen aan in de modus ANSI_QUOTES. SQL Server accepteert ook vierkante haken en accepteert dubbele aanhalingstekens als QUOTED_IDENTIFIER aanstaat, wat de standaard is.

Een herhaalde waarde in een queryresultaat is vaak nuttig. Meerdere medewerkers kunnen in dezelfde plaats wonen en elke medewerker heeft nog steeds een rij nodig. Gebruik DISTINCT als de vraag om verschillende waarden of verschillende combinaties vraagt.

Kies wat als duplicaat moet tellen

SELECT DISTINCT city
FROM employees;

Het resultaat bevat Chicago, Denver en Boston, zonder gegarandeerde volgorde. Het gewone SELECT city zou acht rijen opleveren, omdat elke medewerker een plaats heeft. Toevoeging van DISTINCT beperkt die weergave tot drie verschillende waarden. Alle acht medewerkersrecords blijven in de opslag staan.

De vergelijking omvat elke geselecteerde kolom. Bekijk:

SELECT DISTINCT department, city
FROM employees;

Ana en Chloe leveren allebei (Sales, Chicago) op, dus dat paar komt één keer voor. Emma levert (Sales, Denver) op, dat anders is en behouden blijft. De andere paren zijn (IT, Denver), (Marketing, Boston), (IT, Chicago), (NULL, Boston) en (Marketing, Chicago). Er zijn zeven resultaatrijen. Afdelingen blijven herhaald voorkomen omdat een afdeling met een andere plaats een andere resultaatrij vormt.

Schrijf DISTINCT één keer, direct na SELECT. Het geldt voor de volledige geselecteerde rij. Als je het tussen kolomnamen plaatst, zoals in SELECT department, DISTINCT city, ontstaat een syntaxisfout.

Let op welke kolommen je opneemt

Als je employee_id aan de geselecteerde kolommen toevoegt, wordt elke rij uniek. SELECT DISTINCT employee_id, city FROM employees; levert nog steeds acht rijen op: elke identificatiewaarde is uniek, ook als de plaats wordt herhaald. Om “In welke plaatsen wonen medewerkers?” te beantwoorden, selecteer je alleen de plaats. Om “Welke medewerkers wonen in elke plaats?” te beantwoorden, behoud je identificerende kolommen en verwacht je herhaalde plaatsen.

Bij deze stap waarin duplicaten worden verwijderd, tellen herhaalde NULL-waarden als duplicaten. SELECT DISTINCT department FROM employees; levert Sales, IT, Marketing en één NULL-rij op. De NULL-rij geeft aan dat een afdeling ontbreekt; het is geen vierde afdelingsnaam. Deze regel voor duplicaten verschilt van NULL = NULL, wat in een filter onbekend oplevert.

Tekstvergelijkingen volgen sorteerregels: de regels van de database voor het vergelijken en ordenen van tekst. Met de gewone hoofdlettergevoelige vergelijkingen die in deze voorbeelden voor SQLite en PostgreSQL worden gebruikt, zijn Chicago en chicago verschillende waarden. Een DISTINCT-lijst kan inconsistent hoofdlettergebruik zichtbaar maken. Het verwijderen van herhaalde weergaven herstelt geen spelling in de opgeslagen gegevens.

Combineer DISTINCT met een gesorteerde beperkte lijst

SELECT DISTINCT city
FROM employees
ORDER BY city
LIMIT 2;

Eerst verdwijnen dubbele plaatsen. Daarna worden de drie plaatsen gesorteerd. Tot slot blijven twee resultaatrijen over: Boston en Chicago, in die volgorde. Als je de limiet eerst op medewerkersrijen zou toepassen, zou je een andere vraag beantwoorden.

Neem bij een DISTINCT-query de sorteerkolommen op in de SELECT-lijst. PostgreSQL vereist dit; SQLite staat sommige query's toe die op een niet-geselecteerde kolom sorteren, maar de keuze tussen verschillende verborgen waarden maakt hun volgorde moeilijk te interpreteren. Als een resultaat onverwacht herhalingen bevat, onderzoek dan welke kolommen je hebt geselecteerd voordat je besluit dat DISTINCT in de query thuishoort.

De WHERE-clausule behoudt een rij alleen als de voorwaarde waar is. De clausule volgt op FROM en kan elke kolom in de tabel testen, ook een kolom die je niet weergeeft.

Kies de operator bij de formulering

<> is de standaard-SQL-vorm voor “ongelijk aan”. De vijf databases die hier worden besproken, accepteren ook !=. Gebruik één gelijkteken voor gelijkheid. SQLite accepteert ==, maar PostgreSQL wijst die vorm af.

Volg een rij op de grenswaarde

SELECT first_name, salary
FROM employees
WHERE salary > 60000;

Ben heeft 71.000, Emma heeft 65.000 en Farid heeft 83.000. Dat zijn de drie rijen die voldoen, zonder opgegeven volgorde. David verdient precies 60.000. Zijn rij voldoet niet aan > 60000, omdat “meer dan” gelijkheid uitsluit.

Verander alleen de operator in >=. David komt nu ook in het resultaat, zodat er vier rijen zijn. Zo verschilt “minstens 60.000” van “meer dan 60.000”. Een nuttige grenswaardencontrole vraagt wat er gebeurt met een waarde die precies gelijk is aan de grenswaarde; waarden die er ver boven liggen, kunnen die fout niet aan het licht brengen.

Bij “hoogstens 20,50” voldoet een prijs van 20,50 en valt een prijs van 20,51 af. Als een verzoek zowel een ondergrens als een bovengrens geeft, controleer dan elke grens afzonderlijk voordat je de tests verbindt.

Schrijf numerieke waarden als getallen

Gebruik gewone cijfers in SQL-voorwaarden: 60000, zonder scheidingsteken voor duizendtallen of valutateken. Een komma scheidt SQL-elementen; WHERE salary > 60,000 is een syntaxisfout. Decimale waarden krijgen een punt, zoals in WHERE price < 20.50. Salarissen en prijzen horen in numerieke kolommen, zodat vergelijkingen hun numerieke grootte gebruiken.

Tekst die op een getal lijkt, volgt bij een tekstvergelijking de regels voor tekst. De tekstwaarde '9' wordt na '10' gesorteerd omdat het eerste teken later komt. Dat zegt iets over tekens, niet over of negen groter is dan tien. Bekijk het gegevenstype van de kolom voordat je een onverwachte vergelijking interpreteert.

Filter zonder de geteste kolom weer te geven

SELECT first_name
FROM employees
WHERE salary < 50000;

Chloe en Grace voldoen. Hun salarissen worden gebruikt om de rijen te testen, maar staan niet in het resultaat. Je hoeft het salaris niet aan SELECT toe te voegen om het filter te laten werken. Tijdens het controleren van een query kan het helpen om het salaris tijdelijk te tonen, zodat je ziet waarom elke rij voldeed.

Met een gelijkheidsvergelijking op een primaire sleutel kun je een record direct opzoeken: WHERE employee_id = 6 vindt Farid. Een primaire sleutel identificeert één rij, dus die vergelijking kan niet meerdere medewerkers met dezelfde identificatiewaarde opleveren.

Ontbrekende gegevens vragen aparte aandacht. WHERE stock <> 0 levert zes producten op. Lamp Shade valt af omdat de bekende voorraad nul is. Bookshelf valt ook af: de voorraad is NULL, dus de vergelijking is onbekend en WHERE behoudt het product niet. Een test op “ongelijk aan” voegt geen ontbrekende waarden toe aan het resultaat.

Voorwaarden met tekst en datums hebben waarden nodig in een vorm die de database kan interpreteren. Een verkeerd gespelde waarde kan ongemerkt geen rijen opleveren, terwijl een ontbrekend aanhalingsteken die waarde in een kolomnaam kan veranderen.

Maak onderscheid tussen een waarde en een naam

SELECT first_name
FROM employees
WHERE city = 'Chicago';

Door de enkele aanhalingstekens is 'Chicago' een tekstwaarde. Het resultaat bevat Ana, Chloe, Farid en Hugo. Zonder aanhalingstekens wordt Chicago als naam gelezen, dus zoekt de database naar een kolom met die naam. Ook dubbele aanhalingstekens duiden in de standaard namen aan. PostgreSQL wijst city = "Chicago" af als zo'n kolom niet bestaat. Sommige SQLite-configuraties accepteren tekenreeksen tussen dubbele aanhalingstekens vanwege oud gedrag; gebruik consequent enkele aanhalingstekens voor waarden.

Een apostrof binnen een waarde wordt verdubbeld:

SELECT first_name
FROM employees
WHERE last_name = 'O''Neill';

Dit vindt Hugo. De twee enkele aanhalingstekens naast elkaar stellen één apostrof binnen de waarde voor; de buitenste aanhalingstekens geven het begin en het einde aan. Standaard-SQL gebruikt geen backslash als escape-teken voor die apostrof.

Controleer de vergelijkingsregels

Sorteerregels bepalen de gelijkheid en sortering van tekst, inclusief hoofdletters, kleine letters en letters met accenten. In de gewone hoofdlettergevoelige vergelijkingen van SQLite en PostgreSQL die hier worden gebruikt, verschillen 'Chicago' en 'chicago'. WHERE city = 'chicago' levert geen rijen op. MySQL en SQL Server gebruiken vaak hoofdletterongevoelige sorteerregels, zodat hun gebruikelijke instellingen beide schrijfwijzen kunnen laten overeenkomen.

Ook vergelijkingen van tekstbereiken volgen de sorteerregels. Met deze namen levert WHERE last_name < 'M' Brown, Carter, Haddad, Kim en Lopez op. Waarden worden vanaf links vergeleken. Een langere waarde die met dezelfde tekens begint, komt na het kortere beginstuk: 'Martin' komt na 'M'. Een grenswaarde van 'M' is niet hetzelfde als “alle namen die met M beginnen”.

Zet het jaar voorop

De voorbeeldkolom hire_date slaat volledige datums op als tekst: jaar, maand en dan dag, met vaste breedtes. Daardoor komt de tekstvolgorde overeen met de kalendervolgorde.

SELECT first_name, hire_date
FROM employees
WHERE hire_date >= '2022-01-01';

Chloe, Grace en Hugo voldoen. PostgreSQL heeft ook een echt DATE-gegevenstype dat deze literal accepteert. De standaardvorm met typeaanduiding is DATE '2022-01-01'; SQLite gebruikt die syntaxis voor getypeerde literals niet.

Een lokale datumtekenreeks zoals '03/04/2024' is dubbelzinnig in een datumkolom, omdat instellingen er 4 maart of 3 april van kunnen maken. Als tekst opgeslagen worden datums met de maand voorop eerst op maand en dan op jaar vergeleken. Zo wordt '12/01/2021' na '03/15/2024' gesorteerd, hoewel de eerste kalenderdatum eerder is.

Vertaal de volledige datumgrens

“Aangenomen na 2022” betekent vanaf '2023-01-01'. Als je tekst in plaats daarvan met '2022' vergelijkt, komt Hugo met '2022-08-05' ook mee: de langere tekst wordt na het overeenkomende beginstuk gesorteerd.

Als een kolom tijden bevat, selecteert een gelijkheidsvergelijking met alleen een datum niet alle tijden op die dag. Om 31 maart 2024 mee te nemen, gebruik je ordered_at >= '2024-03-31' AND ordered_at < '2024-04-01'. Dit behoudt elke tijd vanaf het begin van 31 maart tot, maar exclusief, het begin van 1 april.

Een rij moet mogelijk aan meerdere tests voldoen. AND vereist dat beide voorwaarden waar zijn. OR vereist dat minstens één voorwaarde waar is. NOT keert waar en onwaar om; als een voorwaarde door NULL onbekend is, blijft die met NOT onbekend.

Bepaal of beide tests moeten gelden

SELECT first_name
FROM employees
WHERE department = 'Sales' AND city = 'Chicago';

Ana en Chloe voldoen aan beide tests. Emma werkt bij Sales maar woont in Denver, dus voldoet ze niet aan deze AND. Als je AND in OR verandert, komen Emma, Farid en Hugo ook mee: de vijf medewerkers die voldoen, voldoen aan één test of aan beide.

Een AND-voorwaarde toevoegen kan het resultaat gelijk houden of verkleinen. Een OR-voorwaarde toevoegen kan het resultaat gelijk houden of vergroten. Zo kun je snel controleren of een filter klopt als je het in stappen opbouwt.

Elke vergelijking moet volledig zijn. Schrijf department = 'IT' OR department = 'Marketing' en herhaal daarbij de kolom en operator. department = 'IT' OR 'Marketing' drukt de tweede vergelijking niet uit. PostgreSQL wijst dit af; SQLite behandelt de tekst op zichzelf als onwaar en levert alleen IT-medewerkers op. Schrijf op dezelfde manier salary > 50000 AND salary < 70000, met salaris aan beide kanten van AND.

Vertaal groepen alternatieven

“Medewerkers in Boston en Denver” vraagt meestal om mensen in een van beide plaatsen. Elke rij heeft één plaats, dus gebruik city = 'Boston' OR city = 'Denver'. Dat levert Ben, David, Emma en Grace op. Een AND tussen deze gelijkheidsvergelijkingen vraagt dat één plaatswaarde tegelijk beide plaatsen is en levert geen rijen op.

Als operatoren door elkaar worden gebruikt, wordt NOT vóór AND geëvalueerd en AND vóór OR. Zonder haakjes:

WHERE department = 'Sales'
   OR department = 'Marketing' AND city = 'Chicago'

Dit betekent Sales-medewerkers op elke locatie, plus Marketing-medewerkers in Chicago. Emma voldoet omdat de vergelijking met Sales voldoende is. Om beide afdelingen tot Chicago te beperken, groepeer je de alternatieven:

SELECT first_name
FROM employees
WHERE (department = 'Sales' OR department = 'Marketing')
  AND city = 'Chicago';

Nu voldoen Ana, Chloe en Hugo. De haakjes plaatsen de twee afdelingskeuzes onder één gedeelde plaatsvoorwaarde. Gebruik ze om een gemengd AND/OR-filter duidelijk te maken, ook als de standaardvolgorde al juist zou zijn.

Keer een hele groep om

NOT (city = 'Chicago' OR city = 'Denver') levert David en Grace in Boston op. Geen van beide genoemde plaatsen is toegestaan. Voor deze waarden is dit gelijkwaardig aan city <> 'Chicago' AND city <> 'Denver'.

OR gebruiken tussen die twee tests op “ongelijk aan” is een veelvoorkomende valkuil. Een Chicago-rij verschilt van Denver en een Denver-rij verschilt van Chicago. Elke medewerker met een vastgelegde plaats voldoet aan minstens één test, dus de OR sluit geen van beide plaatsen uit.

Bouw een complexe voorwaarde stap voor stap op. Controleer de rijen na de eerste test en daarna opnieuw als je de volgende hebt toegevoegd. Je kunt de twee kanten van een AND of de twee kanten van een OR omwisselen zonder het antwoord te veranderen; kies de volgorde waarin de groepen het makkelijkst te lezen zijn.

Gebruik IN als één kolom met een willekeurige waarde uit een lijst mag overeenkomen. Het verkort een groep gelijkheidsvergelijkingen die met OR zijn verbonden, terwijl de betekenis behouden blijft.

Maak een lijst met alternatieven

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing');

Ben, David, Farid en Hugo voldoen. Ieder van hen heeft een van de twee afdelingswaarden. Dezelfde test kun je schrijven als department = 'IT' OR department = 'Marketing'.

Zet lijstelementen tussen haakjes en scheid ze met komma's. Zet tekst tussen aanhalingstekens; laat die bij numerieke waarden weg. Zo selecteert employee_id IN (2, 4, 6) Ben, David en Farid. De volgorde van de elementen in de lijst sorteert het resultaat niet. Een herhaald element herhaalt geen overeenkomende rij: IN (6, 2, 2, 4) selecteert dezelfde records. Gebruik ORDER BY als je een resultaatvolgorde nodig hebt.

IN vergelijkt volledige waarden volgens dezelfde vergelijkingsregels als gelijkheid. city IN ('Chi') komt niet overeen met Chicago. Bij de gewone hoofdlettergevoelige vergelijkingen die hier worden gebruikt, komt city IN ('chicago') er ook niet mee overeen. Voor een zoekopdracht op een deel van een waarde is LIKE nodig, terwijl de omgang met hoofdletters en kleine letters afhangt van de sorteerregels.

Pas een andere regel toe op elke keuze

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing')
  AND city = 'Chicago';

Farid en Hugo voldoen. IN is één voorwaarde, dus AND past de plaatstest toe op de volledige afdelingskeuze. In de uitgeschreven versie met OR zet je haakjes om de twee afdelingsvergelijkingen. Zonder die haakjes komt bij department = 'IT' OR department = 'Marketing' AND city = 'Chicago' ook Ben mee, omdat AND sterker bindt en de plaatsregel alleen voor Marketing geldt.

Sluit de opgegeven waarden uit

WHERE city NOT IN ('Chicago', 'Denver') levert David en Grace op. Een vastgelegde plaats voldoet alleen als deze van beide elementen verschilt. Dit is een bruikbare vorm voor meerdere uitsluitingen en voorkomt de fout om voorwaarden met “ongelijk aan” met OR te verbinden.

Ontbrekende waarden komen met geen van beide vormen overeen. Grace heeft een NULL-afdeling, dus department NOT IN ('Sales') neemt haar niet mee. De database kan niet vaststellen dat de ontbrekende afdeling verschilt van Sales. Om ook medewerkers zonder toegewezen afdeling mee te nemen, schrijf je department NOT IN ('Sales') OR department IS NULL.

Een NULL binnen een NOT IN-lijst veroorzaakt een groter probleem. department NOT IN ('Sales', NULL) vereist zowel department <> 'Sales' als department <> NULL. De tweede vergelijking is altijd onbekend, dus de gecombineerde test is nooit waar en WHERE levert geen rijen op. Houd tests op ontbrekende waarden gescheiden van de waardenlijst.

Bij IN slaagt een echte overeenkomst nog steeds als een ander lijstelement NULL is. department IN ('Sales', NULL) behoudt de drie Sales-medewerkers, maar voegt Grace niet toe. Gebruik IS NULL om expliciet om ontbrekende waarden te vragen.

Een gewone SQL-IN-lijst heeft minstens één element nodig. PostgreSQL wijst IN () af; SQLite accepteert het als onwaar. Als een programma een lijst opbouwt uit gebruikerskeuzes, verwerk dan een lege lijst voordat je de query verstuurt, zodat het gedrag in alle databases bewust is gekozen.

BETWEEN test een bereik waarbij beide grenzen zijn inbegrepen. Gebruik het als “van” en “tot en met” de genoemde grenswaarden omvatten; gebruik expliciete vergelijkingen als een van beide grenzen moet worden uitgesloten.

Controleer de twee grenzen

SELECT name, price
FROM products
WHERE price BETWEEN 15.50 AND 89.00;

Desk Lamp, Floor Lamp, Lamp Shade en Desk Organizer voldoen. Floor Lamp kost precies 89,00 en Lamp Shade precies 15,50, dus beide blijven behouden. De voorwaarde betekent price >= 15.50 AND price <= 89.00.

Zet de laagste waarde voorop. price BETWEEN 89.00 AND 15.50 vraagt om een prijs van minstens 89,00 en hoogstens 15,50. Het is geldige syntaxis, maar levert geen overeenkomsten op. Gewoon BETWEEN wisselt de grenswaarden niet voor je om. PostgreSQL biedt BETWEEN SYMMETRIC om dat te doen, maar gebruik de vorm met de laagste waarde eerst voor een query die je ook met SQLite gebruikt.

Voor “meer dan 15,50 en minder dan 89,00” schrijf je price > 15.50 AND price < 89.00. Alleen Desk Lamp en Desk Organizer voldoen. Dat verschil gaat over de grenswaarden van de vraag, niet over de manier waarop het resultaat wordt weergegeven.

Buiten een bereik

price NOT BETWEEN 20 AND 100 betekent price < 20 OR price > 100. Het levert Lamp Shade, Office Chair, Standing Desk, Desk Organizer, Bookshelf en Paper Tray op. Waarden van precies 20 of 100 zouden binnen het oorspronkelijke bereik vallen en niet aan NOT BETWEEN voldoen.

Een ontbrekende geteste waarde is in beide tests onbekend. Voor de voorraad selecteert BETWEEN 5 AND 40 vijf producten en NOT BETWEEN selecteert er twee: Lamp Shade met 0 en Desk Organizer met 60. Bookshelf heeft voorraad NULL en hoort in geen van beide resultaten. Een bereik en de ontkenning daarvan hoeven dus niet alle opgeslagen rijen te omvatten.

Datums en tijden

Volledige datumtekenreeksen in de volgorde YYYY-MM-DD ondersteunen datumbereiken. hire_date BETWEEN '2020-01-01' AND '2022-12-31' selecteert Ben, David en Hugo en omvat alle drie kalenderjaren in deze kolom met alleen datums.

Een kolom met tijden heeft voor een hele maand een andere bovengrens nodig. Een grenswaarde met alleen een datum betekent in een tijdstempelkolom middernacht aan het begin van die dag. In tekst wordt zelfs '2024-03-31 00:00:00' na het kortere beginstuk '2024-03-31' gesorteerd. Om alle tijden in maart mee te nemen, gebruik je:

WHERE ordered_at >= '2024-03-01'
  AND ordered_at < '2024-04-01'

Dit sluit het begin van maart in en stopt vlak vóór april, zonder dat je de laatste fractie van een seconde op 31 maart hoeft te raden.

Tekstbereiken en de twee toepassingen van AND

Tekstgrenswaarden zijn volledige waarden. last_name BETWEEN 'A' AND 'C' omvat Brown maar sluit Carter uit, omdat Carter na zijn beginstuk C wordt gesorteerd. Volgens deze tekstregels omvat last_name >= 'A' AND last_name < 'D' namen die met A, B of C beginnen en levert dit Brown en Carter op.

In price BETWEEN 10 AND 100 AND category = 'Lighting' scheidt de eerste AND de grenswaarden van het bereik; de tweede verbindt de bereiktest met de categorietest. De overeenkomende producten zijn Desk Lamp, Floor Lamp en Lamp Shade. Regeleinden kunnen de twee functies duidelijker maken.

LIKE toetst tekst aan een patroon. Gebruik het om naar een begin, een einde of een fragment te zoeken wanneer een gelijkheidsvergelijking om een volledige exacte waarde zou vragen.

Plaats de jokertekens

Het patroon moet overeenkomen met de volledige waarde. % kan nul of meer tekens voorstellen, inclusief spaties. In '%Lamp%' kan elk procentteken met niets overeenkomen, zodat de tekst ook met Lamp kan beginnen of eindigen, naast Lamp in het midden bevatten.

_ staat voor precies één teken. last_name LIKE '_im' vindt Kim. Vier lage streepjes in first_name LIKE '____' vinden Emma en Hugo, de voornamen met precies vier letters. Het lage streepje is geen optioneel teken.

SELECT first_name, phone
FROM employees
WHERE phone LIKE '312-%';

Ana, Chloe en Farid voldoen omdat hun vastgelegde telefoonnummer als tekst met 312- begint. Het procentteken omvat alle overige tekens.

Kies de operator en de regel voor hoofdlettergebruik

Jokertekens horen bij LIKE-patronen. name = '%Lamp%' zoekt naar letterlijke procenttekens en levert hier geen producten op. De jokertekens voor het zoeken naar bestanden * en ? hebben in LIKE geen speciale betekenis; name LIKE 'Desk*' vraagt om de letterlijke asterisk na Desk.

LIKE in SQLite negeert normaal gesproken het verschil tussen hoofdletters en kleine letters voor de ASCII-letters A–Z, terwijl de gewone LIKE in PostgreSQL hoofdlettergevoelig is. name LIKE '%desk%' vindt daarom Desk Lamp, Standing Desk en Desk Organizer in SQLite, maar geen in PostgreSQL met hoofdlettergevoelige sorteerregels. PostgreSQL biedt ook het hoofdletterongevoelige ILIKE. Het gedrag van MySQL volgt de sorteerregels.

Voor de ASCII-productnamen die hier worden gebruikt, levert LOWER(name) LIKE '%desk%' dezelfde overeenkomsten op in SQLite en PostgreSQL: LOWER zet de naam vóór de vergelijking om naar kleine letters. Omzetting van hoofdletters en kleine letters in andere schriftsystemen hangt af van database- en taalregels. Ook de gelijkheidsvergelijking van SQLite verschilt van LIKE: city = 'chicago' vindt Chicago niet volgens de standaard binaire sorteerregels, hoewel city LIKE 'chicago' die plaats wel vindt.

Zoek naar een letterlijk jokerteken

Kies een escape-teken om een laag streepje letterlijk te vergelijken:

WHERE code LIKE 'SPRING!_%' ESCAPE '!'

In een tabel met kortingscodes komt dit overeen met 'SPRING_10', maar niet met 'SPRINGS10'. De !_ is een echt laag streepje; het laatste % komt nog steeds overeen met een reeks. Gebruik dezelfde aanpak met !% voor een letterlijk procentteken. Door ESCAPE expliciet te schrijven ben je niet afhankelijk van de standaardinstellingen van de database; PostgreSQL gebruikt normaal gesproken een backslash en SQLite heeft geen standaard escape-teken.

Ontkenning en omvang van de zoekopdracht

name NOT LIKE '%Lamp%' levert de andere vijf producten op. Ontbrekende tekst voldoet noch aan LIKE, noch aan NOT LIKE. Van de medewerkers komen drie telefoonnummers overeen met '312-%', twee vastgelegde telefoonnummers niet en de drie NULL-telefoonnummers staan in geen van beide resultaten.

Een % aan het begin geeft een gewone index geen vaste begintekst waarmee de zoekopdracht kan worden beperkt, zodat mogelijk een groot deel van de tabel wordt doorzocht. Een vast begin zoals 'Desk%' kan een geschikte index helpen. Gebruik voor datums datumbereiken: LIKE werkt op deze tekstdatums, maar PostgreSQL vereist een conversie voordat je LIKE op een echte DATE-kolom toepast.

NULL duidt een ontbrekende waarde aan: een waarde kan onbekend zijn, niet zijn vastgelegd of niet van toepassing zijn. Dit verschilt van een bekende nul of bekende tekst zonder tekens.

Begrijp wat een ontbrekende waarde betekent

Lamp Shade heeft stock = 0. Het vastgelegde aantal is nul, dus het product is niet op voorraad. Bookshelf heeft stock NULL: het aantal is niet vastgelegd. De database kan je niet vertellen dat er nul eenheden zijn of enig ander aantal.

Dit onderscheid verandert de vraag die je kunt beantwoorden:

Een cel die leeg lijkt in een queryprogramma is niet genoeg om onderscheid te maken tussen deze situaties. Sommige programma's tonen NULL als een lege cel; andere geven NULL weer. Test de opgeslagen waarde rechtstreeks.

Gebruik de tests op ontbrekende waarden

SELECT first_name
FROM employees
WHERE phone IS NULL;

Van Ben, Emma en Hugo is geen telefoonnummer vastgelegd. IS NULL levert waar op voor hun ontbrekende waarden. Om de vijf medewerkers met een vastgelegd telefoonnummer te vinden, gebruik je phone IS NOT NULL: Ana, Chloe, David, Farid en Grace.

Schrijf geen phone = NULL om ontbrekende telefoonnummers te vinden. Een gewone vergelijking met NULL levert onbekend op, zelfs als beide kanten NULL zijn. WHERE behoudt alleen rijen waarvoor de voorwaarde waar is, dus = NULL levert geen rijen op. <> NULL heeft hetzelfde probleem. IS NULL test op de aanduiding voor een ontbrekende waarde en levert voor deze afzonderlijke kolomwaarden een duidelijk antwoord waar of onwaar op.

De vorm NOT phone IS NULL vindt in SQLite en PostgreSQL ook aanwezige telefoonnummers, maar phone IS NOT NULL maakt de bedoelde test makkelijker leesbaar.

Maak onderscheid tussen drie soorten tekst

SQLite, PostgreSQL, MySQL en SQL Server maken onderscheid tussen lege tekst en NULL. phone = '' zou lege tekenreeksen vinden, niet de ontbrekende telefoonnummers van Ben, Emma of Hugo. Als een kolom beide kan bevatten, gebruik dan phone IS NULL OR phone = '' om beide situaties te vinden. Oracle behandelt een lege tekstwaarde als NULL, dus dit onderscheid verandert als je naar een andere database overstapt.

Gebruik de formulering en het schema

“Ontbreekt”, “niet vastgelegd” en “niet toegewezen” wijzen op IS NULL. department IS NULL vindt Grace. Haar ontbrekende afdeling betekent niet dat de afdelingstekst het woord 'NULL' is en stelt ook niet vast bij welke afdeling ze hoort.

De tabeldefinitie kan een kolom als NOT NULL aanduiden, wat betekent dat een opgeslagen rij in die kolom geen NULL kan hebben. Een IS NULL-query op zo'n kolom levert geen rijen op. Controleer deze regel als je een schema bekijkt: kolommen die ontbrekende gegevens toestaan, hebben bijzondere aandacht nodig als je uitsluitingen maakt of voorwaarden combineert.

Een voorwaarde in SQL kan waar, onwaar of onbekend zijn. Ontbrekende waarden maken de derde toestand noodzakelijk: zonder een vastgelegd aantal kan een database niet vaststellen of dat aantal boven een grenswaarde ligt.

Een voorwaarde en het omgekeerde

Voor Bookshelf is stock > 10 onbekend omdat de voorraad NULL is. Dat geldt ook voor stock <= 10. WHERE behoudt alleen rijen waarvoor de voorwaarde waar is en laat rijen met een onware of onbekende voorwaarde weg.

In de productentabel levert stock > 10 vier rijen op en stock <= 10 drie. Samen omvatten ze zeven van de acht producten. Bookshelf ontbreekt in beide. NOT toepassen brengt het product niet terug: NOT onbekend is onbekend, dus NOT (stock > 10) selecteert nog steeds alleen de drie bekende aantallen van hoogstens 10.

Dit verschilt van een waarde die niet aan een voorwaarde voldoet. De bekende nul van Lamp Shade maakt stock > 10 onwaar, dus NOT maakt de voorwaarde waar. Een ontbrekend aantal levert geen dergelijke duidelijke vergelijking op om om te keren.

Combineer onbekend met een andere test

Bookshelf kost 120,00. In stock > 10 OR price > 100 is de prijsvoorwaarde waar. OR heeft maar één waar deel nodig, dus de rij blijft behouden hoewel de voorraadvergelijking onbekend is. In stock > 10 AND price > 100 blijft de voorraadvoorwaarde onbeslist, dus is het resultaat onbekend en valt de rij af.

Neem ontbrekende waarden bewust mee

SELECT first_name
FROM employees
WHERE department <> 'Sales'
   OR department IS NULL;

Dit levert Ben, David, Farid, Hugo en Grace op. De vergelijking alleen zou er vier opleveren en Grace weglaten. De IS NULL-tak neemt expliciet medewerkers mee aan wie geen afdeling is toegewezen. Of zulke medewerkers onder “buiten Sales” vallen, hangt af van het bedoelde antwoord; de query moet die keuze uitdrukken.

Een NULL-waarde in een NOT IN-lijst kan het hele resultaat blokkeren. department NOT IN ('Sales', NULL) betekent dat de afdeling moet verschillen van Sales en van NULL. De laatste vergelijking is voor elke rij onbekend, dus is de volledige voorwaarde nooit waar. IN behoudt echte overeenkomsten nog wel: department IN ('Sales', NULL) selecteert de drie Sales-medewerkers, maar vindt Grace niet.

Een ontbrekende geteste waarde levert ook onbekend op bij LIKE en bij een gewoon BETWEEN-bereik. IS NULL en IS NOT NULL geven duidelijke antwoorden voor deze afzonderlijke kolomwaarden. Controleer ontbrekende waarden afzonderlijk met die tests als een aantal rijen verrassend lijkt.

Weet wanneer NULL-waarden worden gegroepeerd

NULL = NULL blijft onbekend; van twee ontbrekende telefoonnummers is niet bekend of het hetzelfde nummer is. DISTINCT behandelt herhaalde ontbrekende waarden echter als duplicaten en ORDER BY plaatst ze bij elkaar. Voor een vergelijking die twee NULL-waarden bewust als gelijk behandelt, bieden SQLite en PostgreSQL ook IS NOT DISTINCT FROM.

ORDER BY bepaalt de volgorde van resultaatrijen. Zonder ORDER BY doet SQL geen toezegging over welke rij eerst verschijnt, ook niet als een kleine tabel steeds dezelfde volgorde lijkt op te leveren.

Kies de richting

ASC is de standaard. ORDER BY salary en ORDER BY salary ASC vragen om dezelfde richting. “Hoogste salaris eerst” vraagt om ORDER BY salary DESC.

SELECT first_name, salary
FROM employees
ORDER BY salary DESC;

Lees het resultaat van hoog naar laag: Farid 83.000, Ben 71.000, Emma 65.000, David 60.000, Hugo 58.000, Ana 52.000, Chloe 48.000 en Grace 45.000. De database herschikt de resultaatrijen; deze query verandert de opgeslagen tabel niet.

Filter vóór het sorteren

SELECT name, price
FROM products
WHERE category = 'Lighting'
ORDER BY price;

Alleen de drie Lighting-rijen komen in dit resultaat. Hun oplopende prijzen leveren Lamp Shade 15,50, Desk Lamp 24,99 en daarna Floor Lamp 89,00 op. ORDER BY volgt in de instructie op WHERE. Als je die clausules omdraait, ontstaat een syntaxisfout.

De sorteerkolom hoeft niet te worden weergegeven. SELECT first_name FROM employees ORDER BY salary DESC; geeft dezelfde naamvolgorde zonder de salarissen te tonen. PostgreSQL beperkt dit als DISTINCT aanwezig is: een DISTINCT-query moet de sorteerkolommen selecteren.

Bekijk het opgeslagen gegevenstype

Numerieke kolommen worden op numerieke grootte gesorteerd. Tekstkolommen worden op tekens gesorteerd volgens hun sorteerregels. De tekstwaarden '10', '9' en '100' worden bij een gewone tekenvolgorde gesorteerd als '10', '100', '9'. Dat is geen juiste numerieke rangorde, dus controleer het kolomtype als bedragen niet op volgorde lijken te staan.

De voorbeeldwaarden van hire_date zijn volledige tekstdatums met vaste breedte en het jaar voorop. ORDER BY hire_date begint met Farid op 2017-09-12 en eindigt met Grace op 2024-02-19. DESC draait dat om voor de laatst aangenomen medewerkers eerst. Tekstdatums met de maand voorop, zoals MM/DD/YYYY, worden eerst op maand en dan op jaar vergeleken en leveren over meerdere jaren geen betrouwbare kalendervolgorde op.

Tekstvolgorde hangt af van sorteerregels

De standaard binaire sorteerregels van SQLite plaatsen ASCII-hoofdletters vóór kleine letters. Volgens die regel komt 'Zebra' vóór 'apple' en komt 'é' na 'z'. Veel PostgreSQL-databases gebruiken taalafhankelijke sorteerregels die een andere volgorde opleveren. Consistent hoofdlettergebruik helpt, maar de vergelijkingsregels van de database bepalen nog steeds de volgorde van letters met accenten en andere tekens.

Gebruik kolomnamen voor een duidelijke sorteeropgave. ORDER BY 2 DESC betekent het tweede element in de SELECT-lijst, dus als je kolommen verplaatst, kan de sortering ongemerkt veranderen. ORDER BY 'salary' duidt een tekstconstante aan, niet de salariskolom: SQLite levert er geen bruikbare volgorde mee op en PostgreSQL wijst het af. Schrijf ORDER BY salary.

Een tweede sorteerkolom is alleen van belang als rijen in de eerste gelijke waarden hebben. Denk aan een gesorteerde medewerkerslijst: groepeer eerst op plaats en zet daarna de namen binnen elke plaats op volgorde.

Volg de sorteerkolommen van links naar rechts

SELECT last_name, city
FROM employees
ORDER BY city, last_name;

Het resultaat begint met Kim en Okafor in Boston. Daarna komen Haddad, Lopez, Nguyen en O'Neill in Chicago. Brown en Carter in Denver staan als laatste. last_name concurreert niet met city; de kolom bepaalt de volgorde alleen binnen een gedeelde plaats.

Als je de kolommen omdraait, verandert de hoofdvolgorde. ORDER BY last_name, city sorteert voornamelijk op achternaam en kijkt alleen naar de plaats als achternamen gelijk zijn. Gebruik één ORDER BY-clausule met komma's tussen de sorteerkolommen. Een tweede ORDER BY-clausule is ongeldig.

Geef elke kolom een richting

ORDER BY department, salary DESC betekent afdeling oplopend en vervolgens salaris aflopend binnen elke afdeling. DESC hoort alleen bij salaris. Om beide aflopend te maken, schrijf je department DESC, salary DESC.

In de standaard NULL-volgorde van SQLite plaatst de eerste vorm de ontbrekende afdeling van Grace vooraan. IT volgt met Farid en daarna Ben; Marketing heeft David en daarna Hugo; Sales heeft Emma, Ana en daarna Chloe. Je leest één hiërarchie van vergelijkingen; je sorteert niet eerst elke rij op salaris om die volgorde daarna te negeren.

Beslis tussen gelijke waarden met een unieke waarde

Rijen die in alle sorteerkolommen gelijk zijn, kunnen in willekeurige volgorde verschijnen. ORDER BY city bepaalt niet welke medewerker in Chicago eerst komt. Een volledige sorteervolgorde voegt een laatste kolom toe die elke rij uniek identificeert:

SELECT first_name, city
FROM employees
ORDER BY city, employee_id;

De identificatiewaarden beslissen tussen alle gelijke plaatswaarden. Bij ongewijzigde gegevens zorgt dit ervoor dat een latere LIMIT of pagina een herhaalbaar deel van de geordende lijst selecteert. Een unieke aanvullende sorteerkolom bepaalt welke rijen op een grens verschijnen; deze neemt geen extra rijen met gelijke waarden mee.

Plaats ontbrekende waarden bewust

De standaardinstellingen van databases verschillen:

De afdelingsquery zet Grace volgens de standaardinstelling in PostgreSQL dus als laatste, terwijl ze in SQLite als eerste staat. Dit verschil staat los van de salarisrichting.

SELECT first_name, department, salary
FROM employees
ORDER BY department NULLS LAST, salary DESC;

SQLite 3.30 of later, PostgreSQL en Oracle ondersteunen NULLS FIRST en NULLS LAST. Hier zetten ze Grace na alle vastgelegde afdelingen, terwijl de salarisvolgorde binnen elke afdeling behouden blijft. MySQL en SQL Server accepteren die clausules niet.

Vertaal een gevraagde hiërarchie in dezelfde volgorde als waarin die wordt uitgesproken: “op afdeling, binnen elke afdeling het hoogste salaris eerst” levert department, salary DESC op. “Alfabetisch op achternaam, dan voornaam” levert last_name, first_name op. Voeg als laatste een identificatiewaarde toe als je een herhaalbare volgorde nodig hebt tussen mensen met identieke namen.

LIMIT behoudt hoogstens een gekozen aantal resultaatrijen. Het bepaalt niet welke rijen vooraan moeten staan. Gebruik ORDER BY om een beperkte lijst een betekenis te geven, zoals hoogste salaris, nieuwste of goedkoopste.

Sorteer en beperk daarna

SELECT first_name, salary
FROM employees
ORDER BY salary DESC
LIMIT 3;

De gesorteerde salarissen beginnen met Farid 83.000, Ben 71.000 en Emma 65.000, dus die drie rijen blijven over. Zonder ORDER BY levert LIMIT 3 willekeurig drie rijen op, zonder garantie dat ze de hoogste salarissen hebben.

WHERE werkt vóór de limiet. WHERE city = 'Boston' ORDER BY salary DESC LIMIT 5 levert alleen David en Grace op omdat slechts twee medewerkers voldoen. LIMIT is een maximum, geen verzoek om extra rijen te verzinnen. LIMIT 0 levert er geen op.

Sla rijen over voor een latere pagina

OFFSET slaat rijen over voordat LIMIT de op te halen rijen telt. ORDER BY salary DESC LIMIT 3 OFFSET 3 slaat Farid, Ben en Emma over en levert daarna David, Hugo en Ana op: positie vier tot en met zes.

Voor pagina k met n rijen per pagina sla je (k − 1) × n rijen over. Pagina drie met drie rijen per pagina gebruikt LIMIT 3 OFFSET 6. Alleen Chloe en Grace blijven over. De eerste pagina heeft offset nul, niet één.

“De tweede rij” en “de tweede verschillende waarde” zijn verschillende verzoeken. ORDER BY salary DESC LIMIT 1 OFFSET 1 levert hier Ben met 71.000 op. Als twee medewerkers hetzelfde hoogste salaris hadden, zou die query nog een medewerker met het hoogste salaris opleveren. Om het op één na hoogste verschillende salaris te vinden, selecteer je DISTINCT salary voordat je sorteert en rijen overslaat.

Bepaal de grens

ORDER BY city LIMIT 3 bevat de twee medewerkers in Boston en één medewerker in Chicago, maar geeft niet aan welke medewerker in Chicago. ORDER BY city, employee_id LIMIT 3 selecteert David, Grace en Ana. De unieke identificatiewaarde bepaalt de keuze op de grens.

Om iedereen met dezelfde laatste sorteerwaarde te behouden, ondersteunen PostgreSQL 13 of later en Oracle FETCH FIRST 3 ROWS WITH TIES. Met ORDER BY city behoudt dit zes rijen: beide Boston-rijen en alle vier Chicago-rijen. Als ORDER BY ook een unieke identificatiewaarde bevat, kunnen rijen niet gelijk zijn op de volledige sorteersleutel.

Herken de syntaxis van de database

Standaard-SQL gebruikt OFFSET en FETCH, geen LIMIT. PostgreSQL en Oracle accepteren OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY. SQL Server gebruikt ORDER BY salary DESC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY; ORDER BY is verplicht voor deze vorm van paginering.

SQLite en MySQL accepteren ook LIMIT 6, 3, met de offset eerst. Geef de voorkeur aan LIMIT 3 OFFSET 6, zodat de functies expliciet zijn. Bij paginering wordt voor elke pagina opnieuw een query uitgevoerd. Een volledige sorteervolgorde houdt pagina's consistent zolang de gegevens ongewijzigd blijven; toevoegingen of verwijderingen tussen verzoeken kunnen er nog steeds voor zorgen dat pagina's records herhalen of overslaan.

SQL-clausules hebben een vaste volgorde waarin ze worden geschreven. Hun logische volgorde verklaart het resultaat als een reeks beslissingen, ook als de database intern een ander uitvoeringsplan gebruikt.

Schrijf de instructie in clausulevolgorde

SELECT DISTINCT city
FROM employees
WHERE department = 'Sales'
ORDER BY city
LIMIT 2 OFFSET 0;

SELECT en FROM geven de gevraagde kolommen en de brontabel aan. De andere clausules zijn optioneel, maar behouden deze volgorde als ze worden gebruikt: WHERE, ORDER BY, LIMIT en daarna OFFSET in deze LIMIT-vorm. DISTINCT staat direct na SELECT.

Gebruik één WHERE-clausule met meerdere verbonden voorwaarden. Een tweede WHERE is een syntaxisfout. Hetzelfde geldt voor ORDER BY: zet meerdere sorteerkolommen in één clausule, gescheiden door komma's. Als je WHERE onder ORDER BY zet, vraag je niet om een andere verwerkingsvolgorde; je maakt ongeldige SQL.

Volg de logische beslissingen

Het resultaat is Chicago, daarna Denver. De herhaalde plaats verdwijnt voordat de limiet resultaatrijen telt. Je neemt niet eerst twee medewerkers om daarna te vragen of ze in verschillende plaatsen wonen.

De optimalisator kan een ander fysiek uitvoeringsplan gebruiken dat hetzelfde resultaat oplevert als deze logische volgorde.

Gebruik kolommen waar ze beschikbaar zijn

WHERE test de bronrijen voordat SELECT de weergegeven kolommen kiest:

SELECT first_name
FROM employees
WHERE salary > 60000;

Dit werkt zonder salaris in de uitvoer. De namen die voldoen zijn Ben, Emma en Farid. Salaris is nog steeds een kolom van elke bronrij wanneer de test wordt uitgevoerd.

Evenzo is filteren vóór het beperken essentieel voor een eerste resultaat binnen een groep:

SELECT first_name
FROM employees
WHERE department = 'Sales'
ORDER BY salary DESC
LIMIT 1;

Het antwoord is Emma. Eerst voldoen de Sales-medewerkers; daarna worden hun salarissen gerangschikt. Als je eerst de bestbetaalde medewerker van het bedrijf zou nemen en die ene rij op Sales zou testen, zou je het bedoelde antwoord missen, omdat Farid bij IT hoort.

Maak de structuur zichtbaar

Schrijf één clausule per regel en zet langere voorwaarden op afzonderlijke ingesprongen regels. Voor “Furniture-producten onder € 200, hoogste prijs eerst” gebruik je:

SELECT name, price
FROM products
WHERE category = 'Furniture'
  AND price < 200
ORDER BY price DESC;

Office Chair met 149,00 komt vóór Bookshelf met 120,00. De twee voorwaarden delen één WHERE, de numerieke grenswaarde heeft geen valutateken en ORDER BY sorteert de rijen die voldoen. Door elke regel aan de hand van zijn functie te controleren, vind je syntaxisfouten en verkeerde interpretaties makkelijker.

Bepaal voordat je SQL schrijft de afzonderlijke beslissingen die in een alledaags verzoek verborgen zitten. Elke beslissing hoort bij een clausule en elke clausule kun je controleren aan de hand van het bedoelde antwoord.

Neem zes beslissingen

1. Welke tabel bevat de records? Kies FROM.
2. Welke records voldoen? Bouw WHERE op.
3. Welke velden beantwoorden de vraag? Kies SELECT.
4. Zijn herhaalde resultaatwaarden nuttig? Beslis over DISTINCT.
5. Wat moet eerst komen? Bouw ORDER BY op.
6. Is er een maximum of pagina? Voeg LIMIT en OFFSET toe.

Bij “minstens” sluit je gelijkheid in. “Een van” wijst op IN, “bevat” wijst op een LIKE-patroon met procenttekens aan beide kanten, “ontbreekt” wijst op IS NULL en “verschillende waarden” wijst op DISTINCT. Een verzoek om de eerste n resultaten heeft zowel een sorteerrichting als een limiet nodig.

Maak een beperkte medewerkerslijst

“Toon de namen en indiensttredingsdatums van de drie laatst aangenomen medewerkers buiten Sales van wie een telefoonnummer is vastgelegd, de nieuwste eerst.” Neem in dit verzoek medewerkers zonder toegewezen afdeling mee in de betekenis van buiten Sales.

Begin met employees. De afdelingsregel om te voldoen is department <> 'Sales' OR department IS NULL. Groepeer die keuze zodat de telefoonregel voor beide takken geldt. Toon namen en datums en rangschik daarna de rijen die voldoen:

SELECT first_name, last_name, hire_date
FROM employees
WHERE (department <> 'Sales' OR department IS NULL)
  AND phone IS NOT NULL
ORDER BY hire_date DESC
LIMIT 3;

Grace Okafor op 2024-02-19 staat als eerste, David Kim op 2020-11-23 als tweede en Farid Haddad op 2017-09-12 als derde. Als je de IS NULL-tak verwijdert, valt Grace af en blijven slechts twee resultaten over. Bepaal bij een onduidelijk verzoek hoe ontbrekende afdelingen moeten meetellen en vermeld de keuze bij het antwoord.

Combineer categorie, prijs en voorraad

“Welke producten uit Lighting of Storage kosten minder dan € 20 en zijn op voorraad, de goedkoopste eerst?” Gebruik IN voor de twee categoriekeuzes en vereis een bekend positief aantal:

SELECT name, price
FROM products
WHERE category IN ('Lighting', 'Storage')
  AND price < 20
  AND stock > 0
ORDER BY price;

Paper Tray met 9,99 komt vóór Desk Organizer met 18,75. Lamp Shade is goedkoop genoeg en valt in een gekozen categorie, maar de voorraad is nul, dus voldoet het product niet aan de laatste test. Een ontbrekend voorraadaantal zou ook niet voldoen, omdat daarmee niet kan worden vastgesteld dat de voorraad positief is.

Controleer de rijen die een fout kunnen blootleggen

Begin met SELECT * FROM products LIMIT 5; als je het schema en enkele records verkent. Voeg filters één voor één toe, controleer veranderingen in het aantal resultaten en toon geteste kolommen tijdelijk als dat nuttig is.

Test exacte grenswaarden, ontbrekende waarden, hoofdlettergebruik in tekst en gelijke waarden op de limiet. NOT toont rijen waarvoor een voorwaarde onwaar was; het toont geen rijen waarvoor de voorwaarde onbekend was. Voer IS NULL-tests afzonderlijk uit. Controleer of je uitvoer de gevraagde kolommen heeft en of ORDER BY beslist tussen gelijke waarden die het antwoord beïnvloeden.

Controleer bij het overzetten van de query naar een andere database de syntaxis voor rijlimieten, de regels voor hoofdlettergebruik bij gelijkheid en LIKE, aanhalingstekens rond identificatoren, de verwerking van datums en de plaats van NULL. De voorbeelden gebruiken LIMIT in SQLite en PostgreSQL; de rijlimietvorm van standaard-SQL is OFFSET met FETCH FIRST.