Logiske operatorer: $and, $or, $nor, $not

De fleste forespørgselsfiltre indeholder betingelser for flere felter, og de skal ikke alle kombineres med et simpelt AND. Nogle gange ønsker du dokumenter, der opfylder en hvilken som helst af flere betingelser, eller du vil udelukke dokumenter, der matcher et mønster. MongoDB's logiske operatorer – $and, $or, $nor og $not – giver dig fuld boolesk kontrol over filterbetingelserne.

Når du forstår, hvornår hver operator skal bruges, og kender genvejen med implicit AND, bliver dine forespørgsler mere læsbare og effektive.

Når du angiver flere feltbetingelser i ét filterobjekt, anvender MongoDB et implicit OG—alle betingelser skal være sande, for at et dokument matcher. Dette er standardtilfældet og det mest almindelige.

Det implicitte OG er både mere kompakt og en smule mere effektivt end den eksplicitte operator $and, fordi MongoDB kan optimere betingelser på feltniveau uafhængigt af hinanden. Brug implicit OG, når dine betingelser målretter forskellige felter uden tvetydighed.

Eksplicit $and er nødvendigt i én bestemt situation: når du skal anvende flere betingelser på det samme felt med forskellige operatorer, og du ikke kan udtrykke dem i ét objekt (fordi JavaScript-objekter ikke kan have dublerede nøgler).

Det mest almindelige tilfælde er at kombinere to $or-betingelser, der begge refererer til feltet. Intervalbetingelser på ét felt ({ price: { $gte: 20, $lte: 100 } }) fungerer dog fint i ét objekt—eksplicit $and er kun nødvendigt, når udtrykkene ikke kan kombineres til én feltværdi.

$or tager et array med filterbetingelser og matcher dokumenter, hvor mindst én af betingelserne er sand. Det svarer i MongoDB til SQL-nøgleordet OR.

Brug $or, når du har alternative veje til det samme resultat—for eksempel når du vil finde brugere, der enten er administratorer eller har været aktive inden for de seneste 30 dage. En vigtig bemærkning om ydeevne: Hvis hver betingelse har sit eget indeks, kan MongoDB bruge indeksforening til at opfylde forespørgslen—men ét sammensat indeks, der dækker alle betingelser, er ofte hurtigere.

$nor matcher dokumenter, hvor ingen af de angivne betingelser er sande—det er komplementet til $or. Et dokument skal fejle ved ALLE betingelser i $nor-arrayet for at blive returneret.

$nor er mindre almindelig end $or, men er nyttig til udelukkelseslogik: »find produkter, der hverken er udgået, er udsolgt eller tilhører den arkiverede kategori«. Den matcher også dokumenter, hvor de forespurgte felter mangler, eftersom manglende felter ikke matcher nogen positiv betingelse.

$not vender resultatet af ét operatorudtryk på feltniveau om. I modsætning til $nor (som tager et array med komplette filterbetingelser) omslutter $not én operator eller ét regulært udtryk: { price: { $not: { $gt: 100 } } }.

$not matcher også dokumenter, hvor feltet ikke findes. Den er ofte overflødig sammen med $ne eller $nin, men er specifikt nyttig til at negere regulære udtryk: { name: { $not: /^admin/i } }—der findes ingen tilsvarende $ne for regulære udtryk.

Logiske operatorer kan indlejres for at udtrykke vilkårligt kompleks boolesk logik. Tænk på det som at bygge et logiktræ: Ydre $and-betingelser forbindes på øverste niveau, mens $or-underudtryk udtrykker alternativer i en gren.

Komplekse indlejrede booleske forespørgsler kan være svære at læse—overvej at opdele dem i navngivne JavaScript-variabler eller bygge filterobjektet programmatisk ud fra brugerinput i stedet for at indlejre dem fem niveauer dybt i ét objektliterale.

$or-forespørgsler har en særlig adfærd for indeksbrug. MongoDB evaluerer hver gren af $or uafhængigt og fletter resultaterne:

• Hvis hver gren kan bruge et indeks, udfører MongoDB en indeksforening—effektivt
• Hvis en vilkårlig gren ikke kan bruge et indeks, falder MongoDB tilbage til en scanning af samlingen for den gren—det kan være langsomt

Sørg for, at hver gren af $or har et tilsvarende indeks, for at opnå den bedste ydeevne. Når $or-betingelser kan omskrives til $in på det samme felt ({ status: { $in: ['a','b'] } }), bør du gøre det—$in er mere effektiv end en $or med to grene på det samme felt.

I trin i aggregerings-pipelinen som $match fungerer de samme logiske operatorer præcis som i find(). Placér $match med dine logiske betingelser så tidligt som muligt i pipelinen for at reducere antallet af dokumenter, der behandles af efterfølgende trin.

Inde i pipelineudtryk med operatorer (som $project eller $addFields) har logiske operatorer en lidt anderledes syntaks: { $and: [expr1, expr2] } som udtryksoperatorer i stedet for forespørgselsoperatorer. Forespørgsels- ($match-) og udtrykskontekster ($project) bruger de samme operatornavne, men forskellige syntakser.

I virkelige applikationer bygges forespørgselsfiltre ofte dynamisk ud fra brugerinput (søgeformularer, API-parametre). Byg filterobjektet programmatisk, og tilføj kun betingelser, når parameteren er angivet—tilføj ikke et $or: [] med tomme arrays, da det ikke matcher noget.

Validér og rens alle brugerværdier, før du inkluderer dem i en forespørgsel. Send aldrig rå brugerstrenge direkte til $regex uden at escape dem—en angriber kan indsætte et katastrofalt langsomt regulært udtryk (et ReDoS-angreb).

MongoDB evaluerer udtryk med logiske operatorer, men laver IKKE nødvendigvis kortslutning som JavaScript. Forespørgselsplanlæggeren kan omarrangere betingelser af hensyn til effektiviteten—for eksempel flytte en betingelse, der bruger et indeks, foran en, der ikke gør, uanset deres rækkefølge i forespørgselsdokumentet.

En vigtig konsekvens er, at hvis den første gren medfører en fuld scanning af samlingen, kan hele forespørgslen scanne samlingen, selv om den anden gren har et effektivt indeks. Derfor er det så vigtigt for ydeevnen at sikre, at hver gren af er indekseret. Brug explain() til at kontrollere, at udførelsesplanen svarer til dine forventninger.

I denne lektion har du lært: implicit OG er standarden, når du angiver flere felter i ét filterobjekt—eksplicit $and er kun nødvendigt, når du ikke kan udtrykke betingelser som entydige nøgler (f.eks. to $or-blokke), $or matcher enhver enkelt betingelse og bruger indeksforening, når hver gren er indekseret, og $not vender én operator om og er især nyttig til at negere regulære udtryk, hvor $ne ikke kan bruges. Nu ser vi nærmere på elementoperatorer som $exists og $type til håndtering af valgfrie felter og felter med blandede typer.