Write the individual IDs to table B, all with the same "key" (a GUID perhaps).
Then, your query against table A would include
where ID in (select ID from B where key = @TempKey)
(You might then delete the keys if you are finished with them. Or, timestamp them and have a sql job do it later.)
Pros:
- You don't send a string, which could expose you to sql injection in some circumstances.
- Depending on your other app logic, you don't have to track or write the possibilities all at once.
Cons:
- It could be extremely inefficient, especially under heavy loads.
