Logische Operatoren: $and, $or, $nor, $not

Die meisten Abfragefilter enthalten Bedingungen für mehrere Felder, und nicht alle sollten mit einem einfachen AND kombiniert werden. Manchmal benötigen Sie Dokumente, die eine beliebige von mehreren Bedingungen erfüllen, oder Sie möchten Dokumente ausschließen, die einem Muster entsprechen. MongoDBs logische Operatoren – $and, $or, $nor und $not – geben Ihnen vollständige boolesche Kontrolle über Ihre Filterbedingungen.

Wenn Sie wissen, wann welcher Operator verwendet wird und wie die Abkürzung für das implizite AND funktioniert, werden Ihre Abfragen lesbarer und leistungsfähiger.

Wenn Sie mehrere Feldbedingungen in einem einzigen Filterobjekt auflisten, wendet MongoDB sie als implizites AND an – alle Bedingungen müssen erfüllt sein, damit ein Dokument übereinstimmt. Dies ist der Standardfall und zugleich der häufigste.

Das implizite AND ist sowohl kürzer als auch etwas effizienter als der explizite Operator $and, weil MongoDB Bedingungen auf Feldebene unabhängig voneinander optimieren kann. Verwenden Sie das implizite AND immer dann, wenn Ihre Bedingungen auf unterschiedliche Felder abzielen und keine Mehrdeutigkeit besteht.

Ein explizites $and ist in einer bestimmten Situation erforderlich: wenn Sie mehrere Bedingungen auf dasselbe Feld mit unterschiedlichen Operatoren anwenden müssen und diese nicht in einem einzigen Objekt ausdrücken können (da JavaScript-Objekte keine doppelten Schlüssel enthalten können).

Der häufigste Fall ist die Kombination zweier $or-Bedingungen, die beide auf das Feld verweisen. Bereichsbedingungen für ein einzelnes Feld ({ price: { $gte: 20, $lte: 100 } }) funktionieren dagegen problemlos in einem Objekt – ein explizites $and ist nur erforderlich, wenn sich die Ausdrücke nicht zu einem einzigen Feldwert kombinieren lassen.

$or nimmt ein Array von Filterbedingungen entgegen und findet Dokumente, bei denen mindestens eine der Bedingungen erfüllt ist. In MongoDB entspricht dies dem SQL-Schlüsselwort OR.

Verwenden Sie $or, wenn es alternative Wege zum selben Ergebnis gibt – zum Beispiel bei der Suche nach Benutzern, die entweder Administratoren sind oder in den letzten 30 Tagen aktiv waren. Ein wichtiger Hinweis zur Performance: Wenn jede Bedingung separat indiziert ist, kann MongoDB eine Indexvereinigung verwenden, um die Abfrage zu erfüllen. Ein einzelner zusammengesetzter Index, der alle Bedingungen abdeckt, ist jedoch häufig schneller.

$nor findet Dokumente, bei denen keine der angegebenen Bedingungen erfüllt ist – es bildet das Gegenstück zu $or. Ein Dokument muss ALLE Bedingungen im $nor-Array nicht erfüllen, damit es zurückgegeben wird.

$nor wird seltener als $or verwendet, ist aber für Ausschlusslogik nützlich: „Finde Produkte, die weder eingestellt noch nicht vorrätig sind und auch nicht zur archivierten Kategorie gehören.“ Außerdem werden Dokumente gefunden, bei denen die abgefragten Felder fehlen, da fehlende Felder keine positive Bedingung erfüllen.

$not kehrt das Ergebnis eines einzelnen Ausdrucks mit einem Operator auf Feldebene um. Anders als $nor, das ein Array vollständiger Filterbedingungen entgegennimmt, umschließt $not einen einzelnen Operator oder regulären Ausdruck: { price: { $not: { $gt: 100 } } }.

$not findet auch Dokumente, in denen das Feld nicht vorhanden ist. Oft ist der Operator redundant zu $ne oder $nin, aber besonders nützlich zum Negieren regulärer Ausdrücke: { name: { $not: /^admin/i } } – für Regex-Muster gibt es kein entsprechendes $ne.

Logische Operatoren können verschachtelt werden, um beliebig komplexe boolesche Logik auszudrücken. Stellen Sie sich einen Logikbaum vor: Äußere $and-Bedingungen werden auf der obersten Ebene verknüpft, während $or-Teilausdrücke Alternativen innerhalb eines Zweigs ausdrücken.

Komplexe verschachtelte boolesche Abfragen können schwer lesbar sein. Erwägen Sie, sie in benannten JavaScript-Variablen zu speichern oder das Filterobjekt programmgesteuert aus Benutzereingaben aufzubauen, statt es in einem einzigen Objektliteral fünf Ebenen tief zu verschachteln.

$or-Abfragen weisen ein spezifisches Verhalten bei der Indexverwendung auf. MongoDB wertet jeden Zweig von $or unabhängig aus und führt die Ergebnisse zusammen:

• Wenn jeder Zweig einen Index verwenden kann, führt MongoDB eine Indexvereinigung durch – das ist effizient.
• Wenn ein Zweig keinen Index verwenden kann, greift MongoDB für diesen Zweig auf einen Collection-Scan zurück – das kann langsam sein.

Stellen Sie für eine optimale Performance sicher, dass für jeden Zweig von $or ein passender Index vorhanden ist. Wenn sich $or-Bedingungen für dasselbe Feld als $in umschreiben lassen ({ status: { $in: ['a','b'] } }), sollten Sie dies tun – $in ist effizienter als ein zweizweigiges $or für dasselbe Feld.

In Aggregationspipeline-Stufen wie $match funktionieren dieselben logischen Operatoren genauso wie in find(). Platzieren Sie $match mit Ihren logischen Bedingungen so früh wie möglich in der Pipeline, um die Anzahl der Dokumente zu verringern, die von nachfolgenden Stufen verarbeitet werden.

Innerhalb von Pipeline-Ausdrucksoperatoren (wie $project oder $addFields) haben logische Operatoren eine etwas andere Syntax: { $and: [expr1, expr2] } wird dort als Ausdrucksoperator und nicht als Abfrageoperator verwendet. Der Abfragekontext ($match) und der Ausdruckskontext ($project) verwenden dieselben Operatornamen, aber unterschiedliche Syntaxen.

In realen Anwendungen werden Abfragefilter häufig dynamisch aus Benutzereingaben erstellt (Suchformulare, API-Abfrageparameter). Bauen Sie das Filterobjekt programmgesteuert auf und fügen Sie Bedingungen nur hinzu, wenn der jeweilige Parameter angegeben wurde. Fügen Sie kein $or: [] mit leeren Arrays hinzu, da dies keine Dokumente finden würde.

Validieren und bereinigen Sie alle vom Benutzer bereitgestellten Werte, bevor Sie sie in eine Abfrage aufnehmen. Übergeben Sie niemals ungeprüfte Benutzerzeichenfolgen direkt an $regex, ohne sie zu maskieren – ein Angreifer könnte ein extrem langsames Regex-Muster einschleusen (ReDoS-Angriff).

MongoDB wertet Ausdrücke mit logischen Operatoren aus, führt aber NICHT unbedingt wie JavaScript eine Kurzschlussauswertung durch. Der Abfrageplaner kann Bedingungen zur Effizienzsteigerung neu anordnen – beispielsweise eine Bedingung, die einen Index verwendet, vor eine Bedingung verschieben, die keinen Index verwendet, unabhängig von ihrer Reihenfolge im Abfragedokument.

Eine wichtige Folge: In kann der gesamte Abfragevorgang die Collection durchsuchen, wenn der erste Zweig einen vollständigen Collection-Scan verursacht, selbst wenn der zweite Zweig effizient indiziert ist. Deshalb ist es für die Performance so entscheidend, dass jeder Zweig von indiziert ist. Verwenden Sie explain(), um zu überprüfen, ob der Ausführungsplan Ihren Erwartungen entspricht.

In dieser Lektion haben Sie gelernt: Das implizite AND ist der Standard, wenn mehrere Felder in einem Filterobjekt aufgelistet werden – ein explizites $and ist nur erforderlich, wenn sich Bedingungen nicht als eindeutige Schlüssel ausdrücken lassen (z. B. zwei $or-Blöcke). $or findet Dokumente, die eine beliebige Bedingung erfüllen, und verwendet eine Indexvereinigung, wenn jeder Zweig indiziert ist. $not kehrt einen einzelnen Operator um und eignet sich besonders zum Negieren von Regex-Mustern, auf die $ne nicht anwendbar ist. Als Nächstes sehen wir uns Elementoperatoren wie $exists und $type an, mit denen sich optionale Felder und Felder mit gemischten Typen verarbeiten lassen.