T-SQL: Optional table joins?

Question

Let's say I have a stored procedure that will do complicated logic when the parameter @ComplicatedSearch = 1. When it is set to 1, I populate the variable table @ValidIds with valid rows that this procedure can return. When it's 0, the logic is bypassed and we don't need to filter out the rows to return.

So, past that logic, I end up with a statement like so:

SELECT
    m.*
    ,a.*
FROM
    MyTable m
    INNER JOIN AdditionalInfoTable a
       ON m.Id = a.MyTableId
WHERE
   (@ComplicatedSearch = 0 OR EXISTS(SELECT * FROM @ValidIds WHERE Id = m.Id))

This works fine; however, I believe it would be more efficient to join MyTable to @ValidIds when applicable opposed to using EXISTS(), especially when MyTable contains a large number of rows.

Is there any way of doing something like what I have below without writing multiple queries? (the actual query is very large, so having multiple versions with and without joins would not be ideal)

SELECT
    m.*
    ,a.*
FROM
    MyTable m
    ONLY DO THIS IF ComplicatedSearch = 1 PLEASE: INNER JOIN @ValidIds v
       ON m.Id = v.Id
    INNER JOIN AdditionalInfoTable a
       ON m.Id = a.MyTableId

Answer 1

Another option:

SELECT
   m.*     
  ,a.*
FROM MyTable m    
 INNER JOIN @ValidIds v
  ON m.Id = case
              when @ComplicatedSearch = 1 then v.Id  --  Filter rows
              else m.Id  --  Select all rows
            end
 INNER JOIN AdditionalInfoTable a    
  ON m.Id = a.MyTableId

You'd need to do performance testing to see if it's efficient enough. Some quick tests showed that (on my data) the same query plan was generated regardless of whether the first call was for complex or not complex.

The "bifurcated" approach (separate procedures) should be most efficient. However, having the same code with just a minor modification in two different places can be a major pain to support, particularly when you have to add subsequent changes to all "instances" of that code. And if the overall size of the data (e.g. overall performance) isn't too great, the "one size mostly fits all" approach might be most effective.