延迟nm查找存储过程

Question

我有一组对象，它们可以是少数组中的一个或多个的成员（想想可以坐在树内几个位置的对象）。由于需要经常快速地查询这些分配，我们将它们存储为对象中的单个“星座”id，然后保留一个带有星座ID的表，其中每个星座都映射到多个集合（这也节省了我们的一些关于清晰度的麻烦，与INNER JOIN相比，设置了（......）方法中设置的WHERE，这看似更明显。）

示例：对象1和对象2都分配给集合3和4。 而不是保持一个n：m列表

object id | set id
1           3
1           4
2           3
2           4

我们为对象1和2存储星座ID 5，然后有一个表格将第3组和第4组分配给星座5.由于对象往往被分配到集合的常见组合，这在实践中是可行的，即我们不要需要保持2 ^ |集|的整个最坏情况不同的星座。

查询至少一个当前可见集合s1，s2，...中的所有对象，我们找到包含s1或s2或...的所有星座，然后创建查询WHERE constellation IN (constellation1, constellation2, constellation3, ...)

现在我们正在从Access迁移到SQL Server，问题是我们是否应该改变这种方法，因为我们实际上开始创建越来越大的IN子句。

我的问题是：这是存储过程的用例吗？我想要一个像

这样的存储过程

  

SELECT * FROM对象WHERE IsInSet（s1，s2）

其中这个集合列表被转换为相应的星座集合，如果该集合中包含对象的星座，则该函数返回true。由于我只是转移到SQL Server并且从未实际使用过存储过程，因此对于是否有意义的任何反馈都将受到高度赞赏。具体来说，我想知道MSSQL是否会以星座到集合表的缓存方式对其进行优化，因为我们目前正在手动创建查询。

Answer 1

听起来您对FUNCTIONS和STORED PROCEDURES之间的差异感到困惑。

存储过程正是名称所暗示的 - 存储的批处理执行的SQL语句，可以接受参数。它们主要用于创建一致的代码和/或执行计划，并通过使它们更加模块化和划分来简化复杂的流程。它们对于代码重用也很方便。

用户定义函数是传递参数并返回标量值或表，并且可以在查询内部使用，以返回分配给变量或行值的值（如{{1}中所示声明）。

听起来您需要table-valued-function返回一个表格，其中列出了包含您的值的所有集合，然后您可以UPDATE开启。

修改

UDF的替代方法是使用exists子句。没有真正了解你的表格结构，例如：

JOIN

SELECT * FROM objects o WHERE EXISTS ( SELECT NULL FROM Constellations c INNER JOIN ConstellationLookup cl WHERE c.set IN (s1,s2) and cl.ObjectID = o.ObjectID) 短路因此它运行得非常快 - 它找到一个命中并向外部查询返回一个布尔值。