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

让我先说我有偏见;在任何情况下我都讨厌动态SQL。这就是说，这种情况被认为是动态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年）。

来源

2011-07-19 P.Brian.Mackey

看起来像StackOverflow的可能是这个问题比较好。它看起来像你正在解决一些非常糟糕的数据库设计决策。 –

它充满了SQL注入攻击的一件事 –

@Jarrod Roberson-感谢您的纠正。我认为“编译SQL”只是用代码编译的sql。显然情况并非如此。 –

澄清一点：

动态SQL通常采取的一些外部因素的变动情况的语义的意思。换句话说，列名或甚至基表可能被改变。这在过去的数据透视查询中很常见。

这是一种很难说，因为我不知道发生了什么事情到那些要命名为sqlStringX参数做，但我认为这就是我看到的是真的只是内联SQL这恰好是千疮百孔与SQL injection漏洞。这对于parameterize来说非常简单。请尽快修复此问题。内联SQL很好，但没有理由使用原始字符串而不是参数。

来源

2011-07-19 22:17:58 Aaronaught

存储过程将是如何更好地处理这些类型的查询的一个想法。授予存储过程可能只是执行什么参数通过，但这将是我的一种改进代码的方式的建议，以便DBA可以知道哪些索引可能有助于优化查询。像@Jarrod Roberson指出的SQL注入攻击也很可能与这类代码有关。 PS：我在1998年写了这样的代码，其中我写了一个“查找客户”例程的大约20个可能的参数，这是我大学的第一个任务之一，所以我明白这类代码的用途起源。

来源

2011-07-19 22:07:32

+1更不用说，参数化查询在多次调用时会产生更高的性能，这是由于即使使用不同的值，查询缓存多次使用该查询。 – 2011-07-19 22:43:12

@ Surfer513 - 如果使用的选定列和表保持更改，则很少会获得缓存。这些只是在proc中构建动态sql语句的参数，而不仅仅是具有条件的部分。 – JeffO

我同意你的意见。我使用这个理论的基础是假设他可能/可能会多次使用同一个查询。 – 2011-07-19 23:58:32

我会自己使用一个存储过程。但无论如何，无论如何，使用参数。他们的方式，你有它根本就不安全，正如你所说，让我生气看看。 :-)

这里是一个参考，可以帮助（没有存储的特效本身，而是仍然使用PARMS） http://www.asp.net/data-access/tutorials/using-parameterized-queries-with-the-sqldatasource-vb

来源

2011-07-19 22:54:40 Chains

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

回答

相关问题