Du ska filtrera en lista med webbsidor efter kategori, men vill samtidigt hitta titlar som innehåller ett visst ord. SQL:s IN väljer rader med värden ur en lista, medan mönstermatchning oftast görs med LIKE, men NULL-värden och databasmotorer kan ändra vad resultatet blir.
Välj IN för värdelistor och LIKE för textmönster
- IN testar om ett värde finns bland angivna alternativ eller i en underfråga.
- LIKE söker efter textmönster med jokertecken.
- % står för noll eller flera tecken och _ för ett tecken i vanliga LIKE-mönster.
- NOT IN kan ge oväntat resultat om listan eller underfrågan innehåller NULL.
- SQL Server, PostgreSQL och andra databaser kan skilja sig åt i detaljerna för mönster.
IN matchar hela värden, inte delar av text
Om en innehållssida ska tillhöra kategorin “design”, “analys” eller “guider” passar IN bra. Villkoret jämför kolumnvärdet med varje värde i listan och tar med raden när det blir en exakt träff. Microsoft Learn beskriver också IN som en jämförelse mot en lista eller resultatet från en underfråga.
SELECT title, category
FROM pages
WHERE category IN ('design', 'analys', 'guider');Här behöver `category` ha ett av de angivna värdena. En sida med kategorin `designsystem` matchar inte `design`, eftersom IN inte letar efter en textbit inuti ett längre värde. Det är skillnaden som lättast leder till fel filter.
LIKE hittar ett mönster inne i texten
En titel kan innehålla ordet “formulär” utan att hela titeln är just det ordet. Då använder du LIKE och placerar procenttecken där valfria tecken får förekomma. I många SQL-system står `%` för noll eller fler tecken och `_` för exakt ett tecken; PostgreSQLs dokumentation om mönstermatchning beskriver LIKE och dess mönsterregler.
SELECT title
FROM pages
WHERE title LIKE '%formulär%';Procenttecknet på båda sidor gör att ordet kan ligga var som helst i titeln. Byt till `LIKE 'formulär%'` om ordet ska stå först, eller `LIKE '%formulär'` om det ska stå sist. Utan jokertecken blir sökningen i praktiken en jämförelse med hela texten, så välj mönster efter hur innehållet faktiskt ser ut.
Välj operator efter vad kolumnen innehåller
Det tydligaste beslutet kommer av att skilja mellan en avgränsad lista och en fri textkolumn. En kategorikolumn kan filtreras med IN, medan en sidtitel eller beskrivning ofta behöver LIKE. Jag tycker att den uppdelningen är lättare att hålla ren än att försöka pressa in textmönster i en värdelista.
| Situation | Trolig orsak eller effekt | Gör så här |
|---|---|---|
| Kategorin ska vara exakt `design` eller `guider` | Fälten innehåller avgränsade kategorivärden | Använd `category IN ('design', 'guider')` |
| Titeln ska innehålla `design` någonstans | Texten kan ha andra ord före eller efter | Använd `title LIKE '%design%'` |
| En värdelista har många alternativ eller kommer från en tabell | En lång lista blir svår att ändra och överblicka | Använd en underfråga med IN eller koppla tabeller med JOIN |
| Du söker efter ett ord i en kolumn där NULL förekommer | NULL är ett okänt värde, inte tom text | Hantera NULL separat, exempelvis med `IS NULL` eller `COALESCE`, beroende på behov |
Om etiketter lagras som en kommaseparerad sträng, exempelvis `design,guider`, kan LIKE ge falska träffar och göra det svårt att hitta en enskild etikett. För återanvändbara kategorier är en separat relationstabell oftast bättre: då kan IN eller JOIN jämföra riktiga värden i stället för text som råkar innehålla dem.
NOT IN kan filtrera bort mer än du tänkt
En underfråga med NULL kan göra att `NOT IN` inte returnerar de rader du väntar dig. SQL behandlar jämförelsen med NULL som okänd, och då kan ett villkor som verkar betyda “uteslut de här kategorierna” i praktiken ge ett tomt resultat. Microsoft varnar uttryckligen för den här effekten i dokumentationen om IN.
SELECT title
FROM pages
WHERE category NOT IN (
SELECT category
FROM blocked_categories
);Om `blocked_categories.category` innehåller NULL kan resultatet överraska. Kontrollera först om underfrågan ger NULL och filtrera bort det om det inte ska räknas, till exempel med `WHERE category IS NOT NULL` i underfrågan. Om NULL i stället ska behålla eller utesluta vissa sidor behöver det uttryckas separat, inte lämnas åt en implicit jämförelse.
Jokertecken och syntax skiljer sig mellan databaser
En fråga som fungerar i en databas kan behöva justeras i en annan. I SQL Server har LIKE bland annat stöd för hakparentesmönster, medan PostgreSQL erbjuder `ILIKE` som en egen, skiftlägesokänslig variant; Microsofts dokumentation om LIKE i Transact-SQL visar dessutom hur jokertecken kan behandlas som vanliga tecken med särskild syntax.
Om du bara behöver grundläggande matchning med `%` och `_` är LIKE ofta lätt att flytta mellan databaser. Behöver du ignorera stora och små bokstäver, söka efter bokstavliga procenttecken eller använda avancerade uttryck, kontrollera syntaxen för just din motor. Testa också med värden som innehåller mellanslag, understreck och procenttecken, eftersom de kan bete sig som mönstertecken i stället för vanlig text.
En enkel tumregel håller frågan begriplig
För en bestämd uppsättning kategorier väljer du IN. För ett textmönster väljer du LIKE, och när du utesluter värden med NOT IN granskar du NULL i underfrågan innan du litar på resultatet. Då slipper du låta en operatör göra ett jobb den inte är byggd för.
Om samma textfilter återkommer på många sidor är det ofta ett tecken på att kategorier eller taggar bör lagras som separata värden i stället för inuti en längre text. En tydlig datamodell gör filtreringen enklare att skriva och resultaten enklare att förstå.