Conditional WHERE Clauses In A Stored Procedure - sql

Question

This question may boil down to something simpler, but I am still curious as to how close SQL Server / TSQL can get to conditional WHERE clauses (and reasoning behind why they don't exist would also be interesting).
I have a stored procedure that, for a few parameters, takes in an enumeration array (which has been accordingly translated to a user-defined table type which essentially mocks an int array). For reference the data type is as follows:
CREATE TYPE myIntArray AS TABLE (
val INT
);
My stored procedure is along the following lines (altered to be more simplistic):
CREATE PROCEDURE myProc
#homeID INT,
#name VARCHAR(500),
#hometype_enum myIntArray READONLY,
#country_enum myIntArray READONLY
AS
BEGIN
SELECT * FROM my_table
WHERE name=#name
END
GO
What I am wanting to do is additionally filter the results of my query based upon the values of the enum arrays that were passed in as INT tables, IFF they even have values passed in (it is possible the tables might be empty). The pseudo code would look something like this:
SELECT *
FROM my_table
WHERE name = #name
IF((SELECT COUNT(val) FROM #hometype_enum) > 0)
BEGIN
AND hometype IN (SELECT val FROM hometype_enum)
END
IF((SELECT COUNT(val) FROM #country_enum ) > 0)
BEGIN
AND country IN (SELECT val FROM country_enum )
END
The two enums are independent of each other, so it's possible a search could be made and be filtered on no enum (both tables empty), either-or, or both enums.
My actual query involves multiple columns, tables, and unions (ugly, I know), so it's not as nice as just being able to copy/paste a 3-line SELECT for each scenario. I am currently using some pretty ugly temp table logic that I'll spare the reader's eyes from at the moment.
Aside from figuring out my particular problem, my main question is: does SQL Server support conditional WHERE clause statements (I am convinced it does not from my research)? Why is this (architectural, time complexity, space complexity issues)? Are there any more-or-less terse ways to go about emulating a conditional clause, such as taking advantage of conditional short-circuiting?
Thank you all for your insights. Another day of learning!

Answer 1

As suggested in the comments, the best way to handle this kind of conditional where clause would be to use dynamic-sql ..... Something like....
CREATE PROCEDURE myProc
#homeID INT,
#name VARCHAR(500),
#hometype_enum myIntArray READONLY,
#country_enum myIntArray READONLY
AS
BEGIN
SET NOCOUNT ON
Declare #Sql NVarchar(MAX);
SET #Sql = N' SELECT * FROM my_table '
+ N' WHERE name = #name '
+ CASE WHEN EXISTS (Select * FROM #hometype_enum)
THEN N' AND hometype IN (SELECT val FROM hometype_enum) ' ELSE N' ' END
+ CASE WHEN EXISTS (Select * FROM #country_enum)
THEN N' AND country IN (SELECT val FROM country_enum ) ' ELSE N' ' END
Exec sp_executesql #Sql
,N'#homeID INT , #name VARCHAR(500),
#hometype_enum myIntArray, #country_enum myIntArray'
,#homeID
,#name
,#hometype_enum
,#country_enum
END
GO
Using sp_executesql will allow sql server to store parameterised execution plans for the same stored procedure. It is different execution plans for different sets/combinations of a parameters for the same stored procedure for optimal performance.

Answer 2

The below one works fine too. There is no need for dynamic-sql. The MS SQL will handle it without issues (with good performance).
CREATE PROCEDURE myProc
#homeID INT,
#name VARCHAR(500),
#hometype_enum myIntArray READONLY,
#country_enum myIntArray READONLY
AS
BEGIN
SELECT * FROM my_table
WHERE name=#name
AND ( ( SELECT count(val) FROM #hometype_enum ) = 0
OR hometype IN (SELECT val FROM #hometype_enum) )
AND ( ( SELECT count(val) FROM #country_enum ) = 0
OR country IN (SELECT val FROM #country_enum) )
END
GO
The OR will make the job for you. When first part : SELECT count(val) FROM #hometype_enum ) = 0 will return true then the second one will not be executed at all - no error from empty IN clause. When the first part will return some value grater than 0 then the second one will be evaluated correctly.