Hitta antalet överlappande intervall

$lookup pipeline-stadiet i detta sammanhang kommer "alltid" att returnera en array i resultat, även om den är tom. Namnet på utdataegenskapen som "slår samman" med det befintliga dokumentet kommer att vara "överlappar" som anges i "as" egendom till $lookup skede.

Följer $lookup , vi kan sedan göra en enkel $match med ett vanligt frågeuttryck som använder $exists testa för 0 indexvärde för utgångsmatrisen. Om det faktiskt finns något innehåll i arrayen och därför "överlappar" kommer villkoret att vara sant och dokumentet returneras, vilket visar antingen antalet eller dokumenten "överlappar" enligt ditt val.

Andra versioner – frågor att "gå med"

Det alternativa fallet där din MongoDB saknar detta stöd är att "gå med" manuellt genom att utfärda samma frågevillkor som beskrivs ovan för varje granskat dokument:

db.getCollection('collection').find().map( d => {
  var overlaps = db.getCollection('collection').find({
    "_id": { "$ne": d._id },
    "$or": [
      { "starttime": { "$gte": d.starttime, "$lte": d.endtime } },
      { "endtime": { "$gte": d.starttime, "$lte": d.endtime } }
    ]
  }).toArray();

  return ( overlaps.length !== 0 ) 
    ? Object.assign(
        d,
        {
          "overlaps": {
            "count": overlaps.length,
            "documents": overlaps
          }
        }
      )
    : null;
}).filter(e => e != null);

Detta är i huvudsak samma logik förutom att vi faktiskt behöver gå "tillbaka till databasen" för att skicka frågan för att matcha de överlappande dokumenten. Den här gången är det "frågeoperatorerna" som används för att hitta var de aktuella dokumentvärdena ligger mellan de för det bearbetade dokumentet.

Eftersom resultaten redan returneras från servern finns det ingen BSON-begränsning för att lägga till innehåll till utdata. Du kanske har minnesbegränsningar, men det är en annan fråga. Enkelt uttryckt returnerar vi arrayen snarare än markören via .toArray() så vi har de matchande dokumenten och kan helt enkelt komma åt arraylängden för att få en räkning. Om du faktiskt inte behöver dokumenten, använd .count() istället för .find() är mycket effektivare eftersom det inte finns dokumentet som hämtar overhead.

Utdata slås sedan helt enkelt samman med det befintliga dokumentet, där den andra viktiga skillnaden är att eftersom avhandlingar är "flera frågor" finns det inget sätt att tillhandahålla villkoret att de måste "matcha" något. Så detta lämnar oss med tanke på att det kommer att finnas resultat där antalet (eller arraylängden) är 0 och allt vi kan göra just nu är att returnera en null värde som vi senare kan .filter() från resultatmatrisen. Andra metoder för att iterera markören använder samma grundläggande princip att "kassera" resultat där vi inte vill ha dem. Men ingenting hindrar frågan från att köras på servern och denna filtrering är "efterbearbetning" i någon eller annan form.

Minska komplexiteten

Så ovanstående tillvägagångssätt fungerar med strukturen enligt beskrivningen, men naturligtvis kräver den övergripande komplexiteten att du för varje dokument i princip måste granska alla andra dokument i samlingen för att leta efter överlappningar. Därför när du använder $lookup möjliggör viss "effektivitet" i minskningen av transport- och svarskostnader, lider det fortfarande av samma problem att du fortfarande i princip jämför varje dokument med allt.

En bättre lösning "där du kan få den att passa" är att istället lagra ett "hårt värde"* som representerar intervallet på varje dokument. Till exempel skulle vi kunna "förutsätta" att det finns solida "bokningsperioder" på en timme inom en dag för totalt 24 bokningsperioder. Detta "kunde" representeras något i stil med:

{ "_id": "A", "booking": [ 10, 11, 12 ] }
{ "_id": "B", "booking": [ 12, 13, 14 ] }
{ "_id": "C", "booking": [ 7, 8 ] }
{ "_id": "D", "booking": [ 9, 10, 11 ] }

Med data organiserade så där det fanns en inställd indikator för intervallet reduceras komplexiteten avsevärt eftersom det egentligen bara är en fråga om att "gruppera" på intervallvärdet från arrayen inom "booking" egenskap:

db.booking.aggregate([
  { "$unwind": "$booking" },
  { "$group": { "_id": "$booking", "docs": { "$push": "$_id" } } },
  { "$match": { "docs.1": { "$exists": true } } }
])

Och utdata:

{ "_id" : 10, "docs" : [ "A", "D" ] }
{ "_id" : 11, "docs" : [ "A", "D" ] }
{ "_id" : 12, "docs" : [ "A", "B" ] }

Det identifierar korrekt det för 10 och 11 intervall både "A" och "D" innehåller överlappningen, medan "B" och "A" överlappning på 12 . Andra intervall och dokumentmatchning exkluderas via samma $exists testa förutom den här gången på 1 index (eller det andra matriselementet är närvarande) för att se att det fanns "mer än ett" dokument i grupperingen, vilket indikerar en överlappning.

Detta använder helt enkelt $unwind aggregeringspipelinesteget för att "dekonstruera/denormalisera" arrayinnehållet så att vi kan komma åt de inre värdena för gruppering. Det här är exakt vad som händer i $group steg där "nyckeln" som tillhandahålls är bokningsintervallets ID och $push operator används för att "samla in" data om det aktuella dokumentet som hittades i den gruppen. $match är som förklarats tidigare.

Detta kan till och med utökas för alternativ presentation:

db.booking.aggregate([
  { "$unwind": "$booking" },
  { "$group": { "_id": "$booking", "docs": { "$push": "$_id" } } },
  { "$match": { "docs.1": { "$exists": true } } },
  { "$unwind": "$docs" },
  { "$group": {
    "_id": "$docs",
    "intervals": { "$push": "$_id" }  
  }}
])

Med utgång:

{ "_id" : "B", "intervals" : [ 12 ] }
{ "_id" : "D", "intervals" : [ 10, 11 ] }
{ "_id" : "A", "intervals" : [ 10, 11, 12 ] }

Det är en förenklad demonstration, men där data du har skulle tillåta den typ av analys som krävs är detta det mycket effektivare tillvägagångssättet. Så om du kan behålla "granulariteten" som ska fixeras till "inställda" intervall som vanligtvis kan registreras på varje dokument, då kan analysen och rapporteringen använda det senare tillvägagångssättet för att snabbt och effektivt identifiera sådana överlappningar.

I grund och botten är det så här du skulle implementera det du i princip nämnde som ett "bättre" tillvägagångssätt ändå, och det första är en "lätt" förbättring jämfört med vad du ursprungligen teoretiserade. Se vilken som faktiskt passar din situation, men detta bör förklara implementeringen och skillnaderna.