Question

首先让我说我有偏见;在任何情况下我都讨厌动态SQL。话虽这么说，这种情况被认为是动态SQL的好习惯吗？

sqlDataSourceObject.SelectCommand = String.Concat(
                    "select top ", maxRows,
                    "   col1, ",
                    "   col2 as myData, ",
                    "   '' as blah, ",
                    "   col3 as Fromperson ",
                    "   'Corporate' as toPerson, ",
                    "   Convert(char(11), orderDate) as orderDate, ",
                    "   carrier, ",
                    sqlString1,
                    sqlString2,
                    sqlString3 + " AND areaCode = '" + currArea + "'"
                    );

此查询可能会运行一次，然后更改sqlString1,2,3, or currArea的值并再次针对不同的SqlDataSource运行它。

这个代码让我很生气阅读。它难以阅读，它可以随着sqlString变量而改变，我无法运行它而无需复制/粘贴到SSMS中，我必须追踪几个变量才能进行单一更改。

但是，就像我说我有偏见所以我问你。这个代码是在LINQ之前于2001年编写的，与存储过程或其他技术一样好，从良好的实践角度来看一般都可以吗？

如果没有，你会如何改进它（记住没有LINQ，这是2001年）。

Answer 1

澄清一点：

动态SQL 通常用于表示语句的语义基于某些外部因素而发生变化。换句话说，列名称甚至基表可能会被更改。在过去，这对于透视查询来说很常见。

这很难分辨，因为我不知道那些名字很明确的sqlStringX参数是什么，但我认为我在这里看到的只是< em>内联SQL 恰好充满了SQL injection个漏洞。 parameterize很容易。请尽快修复此问题。内联SQL很好，但没有理由使用原始字符串而不是参数。

Answer 2

存储过程是如何更好地处理这些类型的查询的一个想法。当然，存储过程可能只是执行参数传递的内容，但这是我建议的一种方法来改进该代码，以便DBA可以知道哪些索引可能对帮助优化查询有用。 @Jarrod Roberson指出的SQL注入攻击也非常可能出现在这种代码中。

PS：我在1998年编写了这种代码，在编写“查找客户”例程时，我有大约20个可能的参数，这是我在大学之外的第一个任务之一，所以我确实理解这种代码可以来自哪里

Answer 3

我自己使用存储过程。但无论如何，无论如何，都要使用参数。他们的方式你拥有它有没有安全可言的，就像你说的，让我生气的看着。： - ）

这是一个可能有用的参考（不是存储过程本身，但仍使用参数） http://www.asp.net/data-access/tutorials/using-parameterized-queries-with-the-sqldatasource-vb

在这种情况下可以使用动态SQL吗？

3 个答案: