Come richiesto, sto postando la mia versione più semplice della risposta di Piclrow. Ho provato questo sul mio Firebird, che è la versione 2.5, ma l'OP (Steve) lo ha testato su 2.1 e funziona altrettanto bene.
SELECT id
FROM table
WHERE label IN ('Apple', 'Pear', 'Peach')
GROUP BY id
HAVING COUNT(DISTINCT label)=3
Questa soluzione ha lo stesso svantaggio Pilcrow di ... è necessario sapere quanti valori si sta cercando, come il HAVING = condizione deve corrispondere al DOVE IN condizione. In questo senso, la risposta di Ed è più flessibile, in quanto divide il parametro di stringa del valore concatenato e conta i valori. Quindi devi solo cambiare un parametro, invece delle 2 condizioni che uso io e pilcrow.
OTOH, se l'efficienza è preoccupante, preferirei pensare (ma non sono assolutamente sicuro) che l'approccio CTE di Ed potrebbe essere meno ottimizzato dal motore Firebird di quello che suggerisco. Firebird è molto bravo nell'ottimizzare le query, ma in realtà non lo so se è in grado di farlo quando usi CTE in questo modo. Ma WHERE + GROUP BY + HAVING dovrebbe essere ottimizzato semplicemente avendo un indice su (id, label).
In conclusione, se i tempi di esecuzione sono fonte di preoccupazione nel tuo caso, allora probabilmente bisogno di alcuni Spiegare i piani per vedere ciò che sta accadendo, a seconda di quale soluzione scelta;)
Non c'è CTE ("espressione di tabella comune") nella query (o pilcrow) –
Questo commento è stato riferito alla risposta di Ed, che è carina e flessibile, ma ** fa ** usa CTE. Lo renderò più chiaro.Grazie – Frazz
anche con FB2.1. Prenderò questa risposta poiché questa è la domanda più semplice. Grazie! – Steve