PostgreSQL hvor alt er i array

Hvis det antages, at jointabellen følger god praksis og har en unik sammensat nøgle defineret, dvs. en begrænsning for at forhindre duplikerede rækker, så burde noget i stil med følgende simple forespørgsel gøre det.

select conversation_id from conversations_users where user_id in (1, 2)
group by conversation_id having count(*) = 2

Det er vigtigt at bemærke, at tallet 2 i slutningen er længden af ​​listen over bruger-id'er. Det skal naturligvis ændres, hvis user_id-listen ændrer længde. Hvis du ikke kan antage, at din jointabel ikke indeholder dubletter, skal du ændre "count(*)" til "count(distinct user_id)" til en mulig pris i ydeevne.

Denne forespørgsel finder alle samtaler, der omfatter alle de angivne brugere selvom samtalen omfatter også yderligere brugere.

Hvis du kun vil have samtaler med præcis det angivne sæt af brugere, er en fremgangsmåde at bruge en indlejret underforespørgsel i where-sætningen som nedenfor. Bemærk, første og sidste linje er de samme som den oprindelige forespørgsel, kun de to midterste linjer er nye.

select conversation_id from conversations_users where user_id in (1, 2)
   and conversation_id not in
   (select conversation_id from conversations_users where user_id not in (1,2))
group by conversation_id having count(*) = 2

Tilsvarende kan du bruge en set difference-operator, hvis din database understøtter det. Her er et eksempel i Oracle-syntaks. (For Postgres eller DB2 skal du ændre nøgleordet "minus" til "undtagen.)

select conversation_id from conversations_users where user_id in (1, 2)
  group by conversation_id having count(*) = 2
minus
  select conversation_id from conversations_users where user_id not in (1,2)

En god forespørgselsoptimering bør behandle de sidste to varianter identisk, men tjek med din specifikke database for at være sikker. For eksempel sorterer Oracle 11GR2-forespørgselsplanen de to sæt samtale-id'er, før minusoperatoren anvendes, men springer sorteringstrinnet for den sidste forespørgsel over. Så begge forespørgselsplaner kunne være hurtigere afhængigt af flere faktorer såsom antallet af rækker, kerner, cache, indeks osv.