PostgreSQL, gdzie wszystko w tablicy

Zakładając, że tabela łączenia jest zgodna z dobrą praktyką i ma zdefiniowany unikalny klucz złożony, tj. ograniczenie zapobiegające duplikowaniu wierszy, powinno wystarczyć następujące proste zapytanie.

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

Należy zauważyć, że cyfra 2 na końcu to długość listy identyfikatorów użytkowników. To oczywiście musi się zmienić, jeśli długość listy user_id zmieni się. Jeśli nie możesz założyć, że tabela łączenia nie zawiera duplikatów, zmień „count(*)” na „count(distinct user_id)” przy pewnym możliwym koszcie wydajności.

To zapytanie znajduje wszystkie wątki, które obejmują wszystkich określonych użytkowników, nawet jeśli rozmowa obejmuje również dodatkowych użytkowników.

Jeśli chcesz tylko rozmowy z dokładnie określonego zestawu użytkowników, jednym ze sposobów jest użycie zagnieżdżonego podzapytania w klauzuli WHERE, jak poniżej. Zwróć uwagę, że pierwszy i ostatni wiersz są takie same jak oryginalne zapytanie, tylko dwa środkowe wiersze są nowe.

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

Równoważnie możesz użyć operatora różnicowego zestawu, jeśli Twoja baza danych go obsługuje. Oto przykład w składni Oracle. (W przypadku Postgres lub DB2 zmień słowo kluczowe "minus" na "except.)

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)

Dobry optymalizator zapytań powinien traktuj dwie ostatnie odmiany identycznie, ale sprawdź w swojej konkretnej bazie danych, aby się upewnić. Na przykład plan zapytań Oracle 11GR2 sortuje dwa zestawy identyfikatorów konwersacji przed zastosowaniem operatora minus, ale pomija krok sortowania dla ostatniego zapytania. Tak więc każdy plan zapytań może być szybszy w zależności od wielu czynników, takich jak liczba wierszy, rdzeni, pamięci podręcznej, indeksów itp.