Tsql SQL Server 2012-使用游标/dynamicSQL组合是否是一种良好的做法？

最常见的答案是：不，不要使用游标，不要使用动态SQL

但这个问题是从一种看似漂亮但可能是糟糕的做法、更高的处理速度和SQL注入的编码风格中征求反馈

我之所以学习这种风格，是因为我对复制粘贴集查询感到恼火，因为每个查询之间只有一个或两个项目发生变化。我发现这种风格更容易执行代码审查，因为只有一个代码块，不需要上下滚动

一个示例用例是：一个大的慢表，包含来自20家不同保险公司的历史数据，共17亿行200列。为了进行生产性分析，将20家保险公司中的每一家的10列检索到单独的表中

在光标/动态组合之前，为一个计划构建了一个查询并对其进行了代码检查，然后复制了19次，每次都检索不同的计划

使用游标/动态组合后，有一个20项游标和一个动态SQL块。从回顾的角度来看，它似乎更为一致，更不容易出现人为错误

组合的代码示例如下所示：

Declare @company_name varchar(10)
       ,@SQL_STATEMENT varchar(100)

Declare company_cursor cursor fast_forward for  (
SELECT * FROM (VALUES('APPLE'),('GOOGLE'),('AMAZON')) AS TABLE_NAME(COLUMN_NAME)
)

open company_cursor
fetch next from company_cursor into @company_name

while @@fetch_status = 0
begin
    set @SQL_STATEMENT = 'select * from database.schema.'+@company_name
    print (@SQL_STATEMENT)
    fetch next from company_cursor into @company_name 
end 
close company_cursor 
deallocate company_cursor   

我还注意到，使用PRINT而不是EXEC即时打印查询语句，并在将打印结果复制到SQL编辑器中时充当代码生成器

---

有人能提供关于这种T-SQL编码风格的意见、建议或一般实践规则吗？（为落选做好准备…嗅嗅）

好吧，如果

苹果

、

谷歌

和

亚马逊

表都有相同的结构，我想说这里最糟糕的问题是数据库设计错误，公司都需要在一个表上，用一列表示公司名称（或id），而不是每个公司都有一个重复的表。如果不是这样的话，那么游标和动态SQL看起来并不是一个坏的选择。有时候，你必须快速地完成任务。我应该澄清一下，示例代码更像是一个描述cursor/dynamicSQL组合的模板。每当我需要多次运行同一查询，每次运行都指向不同的表或一个/2个where子句发生更改时，我都会使用它。这个用例是一个真实的业务场景：由于我无法控制的力量，我们有一个巨大的表，它非常大，索引非常有限，几乎不可能进行探索性分析。为了解决这个问题，我们从200列中选取10列，创建20个表，每个保险计划对应一个表。两项在查询之间更改：表名和ID