将n：m查找推迟到存储过程

问题描述

| 我有一组对象，它们可以是一个或多个少量集合的成员（请考虑可以在树内多个位置上放置的对象）。由于需要经常快速查询这些分配，因此我们将它们作为单个“星座” 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 ^ | sets |的最坏情况周围的星座不同。 查询当前可见集s1，s2，...中至少一个的所有对象，我们找到所有包含s1或s2或...的星座，然后创建查询

WHERE constellation IN (constellation1,constellation2,constellation3,...)

现在，我们从Access转到SQL Server，问题是我们是否应该改变这种方法，因为实际上我们开始创建越来越大的IN子句。 我的问题是：这将是存储过程的用例吗？我想要一个存储过程，例如   从对象IsInSet（s1，s2）中选择* FROM 其中将这些集合列表转换为相应的星座集合，如果对象的星座包含在该集合中，则该函数返回true。由于我只是转而使用SQL Server，并且从未实际使用过存储过程，因此，对于是否这样做有意义的任何反馈将不胜感激。具体来说，我想知道MSSQL是否会以一种方式来优化此设置，以使星座图集表得以缓存，因为我们目前正在手动创建查询。     

解决方法

听起来您对

FUNCTIONS

和

STORED PROCEDURES

之间的区别有些困惑。 存储过程正是其名称所隐含的含义-存储SQL语句以批处理方式执行，并且可以接受参数。它们主要用于创建一致的代码和/或执行计划，并通过使它们更具模块化和分隔性来简化复杂的流程。它们也很方便代码重用。 用户定义的函数是传递的参数，并返回标量值或表，并且可以在查询中用于返回分配给变量或行值的值（例如在

UPDATE

语句中）。 听起来好像您需要一个表值函数，该函数返回一个表，其中列出了包含您的值的所有集合，然后可以按“ 5”。 编辑： UDF的替代方法是使用exist子句。在不真正了解您的表结构的情况下，类似：

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)

EXISTS

短路，因此运行非常快-找到一个命中并将布尔值返回到外部查询。