Question

我正在开展一个Web项目，我必须检索（比如说）员工记录。在某些情况下，我必须通过提供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

这是一篇关于这个主题的非常全面的文章：

Dynamic Search Conditions in T-SQL by Erland Sommarskog

它涵盖了尝试使用多个可选搜索条件编写查询的所有问题和方法

这是目录：

   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

我认为维护和测试会更容易，你有一个存储过程，每个场景都有一个固定的接口。

Answer 3

据我所知，它没有被推荐。因为每次添加新条件时都必须更改程序，最后你会得到一个难以维护和调试的庞大程序。

如果SP被拆分为多个，那么系统中的其他模块更容易访问它们的特定需求（就像其他一些模块只想通过扇区ID获取emp，那么为什么它们需要通过所有模块可选的参数）。

每次相同的SP发生变化时，每个使用此sp的人都必须更改其DAC。

Answer 4

您的过程有OR，这会阻止它使用索引，而索引的性能会降低。您可以动态构建SQL（sp_executesql），但每次执行时都需要重新编译查询。你失去了存储过程的一些优势（每次使用时都不需要重新编译查询）。如果您决定这样做，请阅读“WITH RECOMPILE”选项。

使用一个接受可变数量参数的存储过程是一种好习惯

4 个答案: