我有一个使用WHERE
子句的查询,并且碰巧在此表的许多查询中使用了完全相同的WHERE
子句(等)。
查询是:
SELECT
DATENAME(DW, [AtDateTime]) AS [Day of Week]
,COUNT(*) AS [Number of Searches]
,CAST(CAST(COUNT(*) AS DECIMAL(10, 2))
/ COUNT(DISTINCT CONVERT(DATE, [AtDateTime])) AS DECIMAL(10, 2))
AS [Average Searches per Day]
,SUM(CASE WHEN [NumFound] = 0 THEN 1 ELSE 0 END)
AS [Number of Searches with no Results]
,CAST(CAST(SUM(CASE WHEN [NumFound] = 0 THEN 1 ELSE 0 END)
AS DECIMAL(10, 2)) / COUNT(*) AS DECIMAL(10, 4))
AS [Percent of Searches with no Results]
FROM [DB].[dbo].[SearchHistory]
WHERE
[CustomerNumber] <> '1234' AND [CustomerNumber] <> '5678'
GROUP BY DATENAME(DW, [AtDateTime]), DATEPART(DW, [AtDateTime])
ORDER BY DATEPART(DW, [AtDateTime])
我希望更改的部分是该WHERE
子句,以便允许我使用一个表,这样,如果我必须添加要忽略的客户编号,则不必更新所有查询。(并且有很多查询具有相同的WHERE
子句。)
如果客户排除项当前特定于查询执行,为什么将它们排除到共享表/工作表中不会引入错误共享?在普通应用程序中,客户通常是任意的,因此特定于单个查询执行。我建议这个问题或者忽略解决方案正常工作所必需的重要事实,或者忽略共享问题。
—
Thomas W
@ThomasW-您所说的“虚假共享”是什么?你有参考吗?我以前从未听说过。
—
Max Vernon
@ThomasW对此的要求是,我们拥有的某些客户(我们经常进行测试)必须从某些报告中排除,因为他们会歪曲结果。
—
Der Kommissar
@MaxVernon -也许更好理解的术语是“范围不正确”。所描述的确实涉及将输入从完全独立的参数更改为跨用户,跨调用的共享DB表。此更改跨越2个范围边界。给定额外的上下文,所描述的范围似乎还可以,但是如果不是这样,它将表现为“错误共享”。
—
Thomas W
所描述的方法还让人想起我负责的主要应用程序中的许多遗留工作表实现(〜1000个表)。在这方面,我提出了可能的“工作台”性质作为问题:)谢谢。
—
Thomas W