Это хорошая практика использовать одну хранимую процедуру, которая принимает переменное количество параметров

Question

Я работаю над веб-проектом, где я должен получить (скажем, записи сотрудников). В некоторых случаях мне нужно получить одну запись, указав EmployeeID. В других случаях мне нужно получить несколько записей о сотрудниках, указав SectorID. Эта логика может быть расширена для охвата дополнительных сценариев: получение всех записей о сотрудниках, получение записей о сотрудниках по квалификации и т. Д.

Рекомендуется ли использовать одну хранимую процедуру, которая принимает переменное число параметров для обработки различных сценариев (использование значений по умолчанию, когда параметр не указан). Пример:

CREATE PROCEDURE [dbo].[GetEmployeeRecords]
(
    @employeeID int = -1,
    @sectorID int = -1
)

AS

BEGIN

    SELECT  EmployeeID,
            EmployeeFirstName,
            EmployeeLastName,
            s.SectorName

    FROM dbo.Employees e

    INNER JOIN Sectors s ON e.SectorID = s.SectorID

    WHERE (e.EmployeeID = @EmployeeID OR @EmployeeID = -1)

    AND (e.SectorID = @SectorID OR @SectorID = -1)

Answer 1

Вот очень обширная статья на эту тему:

Условия динамического поиска в T-SQL Эрланда Соммарского

охватывает все проблемы и методы попытки написания запросов с несколькими необязательными условиями поиска.

вот оглавление:

   Introduction
      The Case Study: Searching Orders
      The Northgale Database
   Dynamic SQL
      Introduction
      Using sp_executesql
      Using the CLR
      Using EXEC()
      When Caching Is Not Really What You Want
   Static SQL
      Introduction
      x = @x OR @x IS NULL
      Using IF statements
      Umachandar's Bag of Tricks
      Using Temp Tables
      x = @x AND @x IS NOT NULL
      Handling Complex Conditions
   Hybrid Solutions – Using both Static and Dynamic SQL
      Using Views
      Using Inline Table Functions
   Conclusion
   Feedback and Acknowledgements
   Revision History

Answer 2

Это не рекомендуется, как я знаю. Потому что вы должны менять свою процедуру каждый раз, когда добавляются новые критерии, и, наконец, вы получите массивный, который сложно поддерживать и отлаживать.

Если SP разделен на несколько, тогда другим модулям в вашей системе будет проще получить доступ к их конкретным потребностям (как, например, какой-то другой модуль хотел получить emp только по идентификатору сектора, тогда зачем им передавать все необязательные параметры).

И каждый раз, когда меняется один и тот же SP, каждый потребляющий этот SP должен менять свой ЦАП.

Answer 3

Ваша процедура имеет ИЛИ, что не позволяет ей использовать индексы, что приводит к снижению производительности. Вы можете построить SQL динамически (sp_executesql), но для этого потребуется перекомпилировать запрос каждый раз, когда он выполняется. Вы теряете некоторые преимущества, которые имеют хранимые процедуры (нет необходимости перекомпилировать запрос каждый раз, когда он используется). Если вы решите это сделать, прочитайте о опции «С РЕКОМЕНДУЕМЫМ».

Answer 4

Я думаю, что будет проще поддерживать и тестировать, если у вас есть одна хранимая процедура с фиксированным интерфейсом для каждого сценария.