问题描述
- 存储过程不让拼接SQL语句
-
公司DBA不允许创建的存储过程中有拼接SQL语句的行为，请问，该怎么解决？说是这样做有风险，说我非要用的话，可以签一份风险协议，出了问题我负责之类的。请问：各位在多条件查询这种情况下，存储过程都是怎么写的？有不拼接又省事的办法吗？另外，这个风险难道微软没有提供解决方案吗？
解决方案
真正的风险， 不在于拼SQL， 而是输入值没有参数化。
比如：
delare @sql nvarchar(max), @name nvarchar(20)
set @name='小明'
set @sql = 'select * from user where username like ''%'+@name+'%'''
--下面有风险
exec (@sql)
--下面这种无风险
set @sql = 'select * from user where username like ''%@name%'''
exec sp_executesql
@stmt=@sql,
@params =N'@name as nvarchar(20)',
@name=@name
其实道理很简单， 如果都是sqlserver内部、数据库内部、你自己写的东西 比如 select , from , where 之类的肯定没有问题， 不用怕。
怕的是什么呢？怕的是外部传过来的东西——比如上面的@name， 这个是从网站的页面传过来的， 如果不用参数化， 绝对有sql注入风险！
如果你还有疑问， 可以列出具体的例子来， 我可以为你尽力解答！
解决方案二：
拼接sql是可能被注入的，所以尽量少用加号来拼接，可以用参数的形式进行参数化查询
解决方案三：
存储过程参数化啊 我们公司都是这么做的 比拼接sql即方便又效率还易懂。
解决方案四：
看你用的什么开发环境，拼接的解决方案 现在只有 oracle + java 可以实现 ，真正的实现 语句和参数的分离 。 现在市场所有的 orm 的最终 运行都是 拼接出来的 sql。
普通的 关系型数据库 例如 mysql mssql 等 只能是在 数据类型方面 和 符号转换方面做文章了。
解决方案五：
- 简单的方法是使用命令参数。
- 更好点的办法是对每个查询简历存储过程。
- Dotnet使用参数的方法，供参考http://www.docin.com/p-138438325.html
解决方案六：
可以拼接，使用参数或者直接拼接就而已了。
解决方案七：
多搞几个参数吧，为了安全规范，总要牺牲点什么。忍了吧。
解决方案八：
使用SQLiteDatabase，传参的形式查询
SQLiteDatabase db = helper.getReadableDatabase();
Cursor c = db.query("TableName", null, null, null, null, null, null);
具体参见http://www.cnblogs.com/maxinliang/archive/2013/01/22/2871474.html