How can I write a better stored procedure to return all records with a flag/bit field = 1 in which I pass the flag-field's name into the sproc? - sql-server

Question

I'm dealing with a substantially more complicated schema (of course), but I think i'm including just enough in this question to show what I need and no more. (I'll update as needed based on comments.) Let's say I have this table:
create table peeps (
id int primary key identity(1,1),
name varchar(50),
eligible bit,
lefty bit,
contractor bit
)
And I want to write a sproc that's going to return the names of all my peeps if they are eligible or lefties or contractors and I want to have a single procedure to handle all those cases.
My current approach to this (which seems to totally work) looks like this:
CREATE PROCEDURE getFlagMatchingPeeps #flagName varchar(30)
select name
from peeps
where
(eligible = 1 or eligible = case when #flagName = 'eligible' then 1 else 0 end) and
(lefty = 1 or lefty = case when #flagName = 'lefty' then 1 else 0 end) and
(contractor = 1 or contractor = case when #flagName = 'contractor' then 1 else 0 end)
But that feels like an ugly solution (e.g. testing whether a value is 1 twice feels wasteful). So I'm here looking for more advanced SQL people to help me craft something better.
I guess first, is there anything wrong with my solution? If not, this can be quick. But if there is:
What is it?
What's the right approach?
How should I have identified the problem?
How should I be thinking differently in order to solve this?

Answer 1

If you just wanted to get rid of the extra comparison (for simplicity, this assumes that the bit columns are non-nullable contrary to the defined schema)
SELECT
[name]
FROM
[dbo].[peeps]
WHERE
([eligible] = CASE WHEN #flagName = 'eligible' THEN 1 ELSE [eligible] END) AND
([lefty] = CASE WHEN #flagName = 'lefty' THEN 1 ELSE [lefty] END) AND
([contractor] = CASE WHEN #flagName = 'contractor' THEN 1 ELSE [contractor] END);
Ignoring the fact that you are filtering on bit columns, in general there will be performance issues with queries using dynamic search parameters without the use of OPTION(RECOMPILE) or dynamic sql due to parameter sniffing. See Erland Sommarskog's article on this topic.