18 个解决方案
#1
统一用存储过程来处理，免得你要加条件的时候还要改代码
都使用存储过程，在发布后修改的时候就可以不修改程序，而只处理数据库了。
都使用存储过程，在发布后修改的时候就可以不修改程序，而只处理数据库了。
#2
个人感觉：1.放入存储过程执行效率更高，但是单条语句效果估计不会太明显。
2.独立于系统程序，如果后期需要修改SQL语句，直接在存储过程中修改，
避免了在程序中修改SQL语句，需要发布新程序的麻烦。
--个人拙见啊！
2.独立于系统程序，如果后期需要修改SQL语句，直接在存储过程中修改，
避免了在程序中修改SQL语句，需要发布新程序的麻烦。
--个人拙见啊！
#3
直接拼sql，容易被注入的。
#4
容易被注入是什么意思？
#5
为了安全最好还是些存储过程吧！这样更大程度的防止sql注入。
另外存储过程优点还是比较多的：更好的程序的移植和模块化的。
另外存储过程优点还是比较多的：更好的程序的移植和模块化的。
#6
存储过程多也不是好事，一些固定的单句执行，写字符串可以的。
#7
SQL注入是以前黑客常用的入侵的一种方式，给你系统多搞一下错误，猜猜说不定就把数据插入到你数据库中了。
#8
储存过程经过编译优化过，执行效率会高点。
#9
这样做好处很多.
关键问题是老大都这么说了,如果你还把SQL语句嵌入到程序上,要是我肯定...............
关键问题是老大都这么说了,如果你还把SQL语句嵌入到程序上,要是我肯定...............
#10
主要是我感觉把sql语句放在程序上很方便对表的更新，如果一个表有十几个字段，我要更新数据的话那我就要传入十几个参数给存储过程，如果增加表字段，那我不但要修改程序，而且要修改存储过程，这麻烦就大了
#11
如果系统是你们自己用，爱写哪儿写哪儿
要是卖给客户用，最好还是用存储过程。
要是卖给客户用，最好还是用存储过程。
#12
-- 10.1 存储过程基础 ( P273 )(摘录于 SQL Server 2008实战\第10章_存储过程(P273页)
-- 这几年，我已经形成了一个只要有可能就使用存储过程的强烈偏好。根据我的经验，使用存储过程有很多好处，而没什么坏处。通常，
-- 反对使用存储过程的理由来自某些应用程序开发者，他们更喜欢在应用层使用即席SQL (adhoc SQL)，并且没有训练过使用存储过程。与独立的应用程序和数据库管理员一起，
-- 存储过程同样面临着开发人员到数据库管理员对T-SQL代码的失控。假设你们的数据库管理团队很强，并且乐意及时提供向存储过程转移的帮助，
-- 那么使用存储过程的优势会比失去控制大很多。
-- 使用存储过程有以下一些好处。
-- *1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改，当即席SQL嵌入在应用程序内的时候，你可能会花费太多时间试图找到和调试嵌入的SQL。
-- 一旦找到了bug，你可能就需要重新编译可执行程序，引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去，
-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化，存储过程就会提升整个应用程序的可支持性。
-- *2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程，对网络以及应用程序的性能有正面影响，特别是当调用在一分钟内重复数千次时。
-- *3) 存储过程促进代码的可利用性。例如，如果你的网站应用程序使用一个下拉菜单来包含一组城市，并且这个下拉菜单用于很多网页，
-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
-- *4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表，存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。
-- 你可以把老的表换成新的，而且只要同样的列和数据类型返回给应用程序，则应用程序完全不知情。
-- *5) 与视图不同，存储过程可以利用流控制技术、临时表、表变量等。
-- *6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询，可能会注意到有时候从查询中返回结果所花的时间变化很大。
-- 这可能由诸如对表(锁)的并发活动或者资源问题(内存、CPU)等外部因素引起的。从另外一面来说，即席查询可能执行得不稳定，因为SQL Server有时候会选择效率较低的执行计划。
-- 而存储过程提供了更可靠的查询计划缓存，因此可以重用。注意到，这里我使用的是“可靠”这个单词，而不是“快速”。即席查询有时候确实比存储过程执行得更好，
-- 但是它完全依赖执行计划被缓存的环境(“被发觉”的参数)，以及看你怎么测试、调优以及实现代码了。
-- 如果前面的这些理由还不能让你相信存储过程是非常好的，那么让我们再来看一下安全方面的好处。直接访问SQL Server实例和它的数据库的表(更坏的情况是访问sysadmin)会引起安全隐患。
-- 内联即席代码特别容易遭受SQL注入(injection)攻击。如果在T-SQL发送到SQL Server实例之前，有害的T-SQL就插入到了既有应用程序的T-SQL代码，那么就会发生SQL注入。除了SQL注入攻击，
-- 如果一些人得到了内联代码，他们就能收集数据库中基础架构的信息，从而指导他们尝试攻击。让所有SQL在存储过程内能保证只有存储过程被应用程序引用----而不是每一个列和表名。
-- 存储过程的另外一个安全方面的好处就是可以授予数据库用户和/或数据库角色对它们的访问而不是授予对表的直接访问权限。存储过程能作为控制层，
-- 你可以选择哪些列和行能被存储过程(和调用者)修改，哪些不能。
-- 这几年，我已经形成了一个只要有可能就使用存储过程的强烈偏好。根据我的经验，使用存储过程有很多好处，而没什么坏处。通常，
-- 反对使用存储过程的理由来自某些应用程序开发者，他们更喜欢在应用层使用即席SQL (adhoc SQL)，并且没有训练过使用存储过程。与独立的应用程序和数据库管理员一起，
-- 存储过程同样面临着开发人员到数据库管理员对T-SQL代码的失控。假设你们的数据库管理团队很强，并且乐意及时提供向存储过程转移的帮助，
-- 那么使用存储过程的优势会比失去控制大很多。
-- 使用存储过程有以下一些好处。
-- *1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改，当即席SQL嵌入在应用程序内的时候，你可能会花费太多时间试图找到和调试嵌入的SQL。
-- 一旦找到了bug，你可能就需要重新编译可执行程序，引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去，
-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化，存储过程就会提升整个应用程序的可支持性。
-- *2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程，对网络以及应用程序的性能有正面影响，特别是当调用在一分钟内重复数千次时。
-- *3) 存储过程促进代码的可利用性。例如，如果你的网站应用程序使用一个下拉菜单来包含一组城市，并且这个下拉菜单用于很多网页，
-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
-- *4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表，存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。
-- 你可以把老的表换成新的，而且只要同样的列和数据类型返回给应用程序，则应用程序完全不知情。
-- *5) 与视图不同，存储过程可以利用流控制技术、临时表、表变量等。
-- *6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询，可能会注意到有时候从查询中返回结果所花的时间变化很大。
-- 这可能由诸如对表(锁)的并发活动或者资源问题(内存、CPU)等外部因素引起的。从另外一面来说，即席查询可能执行得不稳定，因为SQL Server有时候会选择效率较低的执行计划。
-- 而存储过程提供了更可靠的查询计划缓存，因此可以重用。注意到，这里我使用的是“可靠”这个单词，而不是“快速”。即席查询有时候确实比存储过程执行得更好，
-- 但是它完全依赖执行计划被缓存的环境(“被发觉”的参数)，以及看你怎么测试、调优以及实现代码了。
-- 如果前面的这些理由还不能让你相信存储过程是非常好的，那么让我们再来看一下安全方面的好处。直接访问SQL Server实例和它的数据库的表(更坏的情况是访问sysadmin)会引起安全隐患。
-- 内联即席代码特别容易遭受SQL注入(injection)攻击。如果在T-SQL发送到SQL Server实例之前，有害的T-SQL就插入到了既有应用程序的T-SQL代码，那么就会发生SQL注入。除了SQL注入攻击，
-- 如果一些人得到了内联代码，他们就能收集数据库中基础架构的信息，从而指导他们尝试攻击。让所有SQL在存储过程内能保证只有存储过程被应用程序引用----而不是每一个列和表名。
-- 存储过程的另外一个安全方面的好处就是可以授予数据库用户和/或数据库角色对它们的访问而不是授予对表的直接访问权限。存储过程能作为控制层，
-- 你可以选择哪些列和行能被存储过程(和调用者)修改，哪些不能。
#13
[align=center]如果这条SQL语句比较长或者经常被调用的话，用存储过程会比较好。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。[/align]
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。[/align]
#14
如果这条SQL语句比较长或者经常被调用的话，用存储过程会比较好。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。
#15
要的就是规范
#16
就是规定，遵守就行了。
其实坏处也是有的，将来某天换个oracle数据库，这些存储过程就基本废掉了。。。
其实坏处也是有的，将来某天换个oracle数据库，这些存储过程就基本废掉了。。。
#17
该回复于2011-02-23 09:14:30被版主删除
#18
那就看你这东西是不是要经常修改、
#1
统一用存储过程来处理，免得你要加条件的时候还要改代码
都使用存储过程，在发布后修改的时候就可以不修改程序，而只处理数据库了。
都使用存储过程，在发布后修改的时候就可以不修改程序，而只处理数据库了。
#2
个人感觉：1.放入存储过程执行效率更高，但是单条语句效果估计不会太明显。
2.独立于系统程序，如果后期需要修改SQL语句，直接在存储过程中修改，
避免了在程序中修改SQL语句，需要发布新程序的麻烦。
--个人拙见啊！
2.独立于系统程序，如果后期需要修改SQL语句，直接在存储过程中修改，
避免了在程序中修改SQL语句，需要发布新程序的麻烦。
--个人拙见啊！
#3
直接拼sql，容易被注入的。
#4
容易被注入是什么意思？
#5
为了安全最好还是些存储过程吧！这样更大程度的防止sql注入。
另外存储过程优点还是比较多的：更好的程序的移植和模块化的。
另外存储过程优点还是比较多的：更好的程序的移植和模块化的。
#6
存储过程多也不是好事，一些固定的单句执行，写字符串可以的。
#7
SQL注入是以前黑客常用的入侵的一种方式，给你系统多搞一下错误，猜猜说不定就把数据插入到你数据库中了。
#8
储存过程经过编译优化过，执行效率会高点。
#9
这样做好处很多.
关键问题是老大都这么说了,如果你还把SQL语句嵌入到程序上,要是我肯定...............
关键问题是老大都这么说了,如果你还把SQL语句嵌入到程序上,要是我肯定...............
#10
主要是我感觉把sql语句放在程序上很方便对表的更新，如果一个表有十几个字段，我要更新数据的话那我就要传入十几个参数给存储过程，如果增加表字段，那我不但要修改程序，而且要修改存储过程，这麻烦就大了
#11
如果系统是你们自己用，爱写哪儿写哪儿
要是卖给客户用，最好还是用存储过程。
要是卖给客户用，最好还是用存储过程。
#12
-- 10.1 存储过程基础 ( P273 )(摘录于 SQL Server 2008实战\第10章_存储过程(P273页)
-- 这几年，我已经形成了一个只要有可能就使用存储过程的强烈偏好。根据我的经验，使用存储过程有很多好处，而没什么坏处。通常，
-- 反对使用存储过程的理由来自某些应用程序开发者，他们更喜欢在应用层使用即席SQL (adhoc SQL)，并且没有训练过使用存储过程。与独立的应用程序和数据库管理员一起，
-- 存储过程同样面临着开发人员到数据库管理员对T-SQL代码的失控。假设你们的数据库管理团队很强，并且乐意及时提供向存储过程转移的帮助，
-- 那么使用存储过程的优势会比失去控制大很多。
-- 使用存储过程有以下一些好处。
-- *1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改，当即席SQL嵌入在应用程序内的时候，你可能会花费太多时间试图找到和调试嵌入的SQL。
-- 一旦找到了bug，你可能就需要重新编译可执行程序，引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去，
-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化，存储过程就会提升整个应用程序的可支持性。
-- *2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程，对网络以及应用程序的性能有正面影响，特别是当调用在一分钟内重复数千次时。
-- *3) 存储过程促进代码的可利用性。例如，如果你的网站应用程序使用一个下拉菜单来包含一组城市，并且这个下拉菜单用于很多网页，
-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
-- *4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表，存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。
-- 你可以把老的表换成新的，而且只要同样的列和数据类型返回给应用程序，则应用程序完全不知情。
-- *5) 与视图不同，存储过程可以利用流控制技术、临时表、表变量等。
-- *6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询，可能会注意到有时候从查询中返回结果所花的时间变化很大。
-- 这可能由诸如对表(锁)的并发活动或者资源问题(内存、CPU)等外部因素引起的。从另外一面来说，即席查询可能执行得不稳定，因为SQL Server有时候会选择效率较低的执行计划。
-- 而存储过程提供了更可靠的查询计划缓存，因此可以重用。注意到，这里我使用的是“可靠”这个单词，而不是“快速”。即席查询有时候确实比存储过程执行得更好，
-- 但是它完全依赖执行计划被缓存的环境(“被发觉”的参数)，以及看你怎么测试、调优以及实现代码了。
-- 如果前面的这些理由还不能让你相信存储过程是非常好的，那么让我们再来看一下安全方面的好处。直接访问SQL Server实例和它的数据库的表(更坏的情况是访问sysadmin)会引起安全隐患。
-- 内联即席代码特别容易遭受SQL注入(injection)攻击。如果在T-SQL发送到SQL Server实例之前，有害的T-SQL就插入到了既有应用程序的T-SQL代码，那么就会发生SQL注入。除了SQL注入攻击，
-- 如果一些人得到了内联代码，他们就能收集数据库中基础架构的信息，从而指导他们尝试攻击。让所有SQL在存储过程内能保证只有存储过程被应用程序引用----而不是每一个列和表名。
-- 存储过程的另外一个安全方面的好处就是可以授予数据库用户和/或数据库角色对它们的访问而不是授予对表的直接访问权限。存储过程能作为控制层，
-- 你可以选择哪些列和行能被存储过程(和调用者)修改，哪些不能。
-- 这几年，我已经形成了一个只要有可能就使用存储过程的强烈偏好。根据我的经验，使用存储过程有很多好处，而没什么坏处。通常，
-- 反对使用存储过程的理由来自某些应用程序开发者，他们更喜欢在应用层使用即席SQL (adhoc SQL)，并且没有训练过使用存储过程。与独立的应用程序和数据库管理员一起，
-- 存储过程同样面临着开发人员到数据库管理员对T-SQL代码的失控。假设你们的数据库管理团队很强，并且乐意及时提供向存储过程转移的帮助，
-- 那么使用存储过程的优势会比失去控制大很多。
-- 使用存储过程有以下一些好处。
-- *1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改，当即席SQL嵌入在应用程序内的时候，你可能会花费太多时间试图找到和调试嵌入的SQL。
-- 一旦找到了bug，你可能就需要重新编译可执行程序，引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去，
-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化，存储过程就会提升整个应用程序的可支持性。
-- *2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程，对网络以及应用程序的性能有正面影响，特别是当调用在一分钟内重复数千次时。
-- *3) 存储过程促进代码的可利用性。例如，如果你的网站应用程序使用一个下拉菜单来包含一组城市，并且这个下拉菜单用于很多网页，
-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
-- *4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表，存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。
-- 你可以把老的表换成新的，而且只要同样的列和数据类型返回给应用程序，则应用程序完全不知情。
-- *5) 与视图不同，存储过程可以利用流控制技术、临时表、表变量等。
-- *6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询，可能会注意到有时候从查询中返回结果所花的时间变化很大。
-- 这可能由诸如对表(锁)的并发活动或者资源问题(内存、CPU)等外部因素引起的。从另外一面来说，即席查询可能执行得不稳定，因为SQL Server有时候会选择效率较低的执行计划。
-- 而存储过程提供了更可靠的查询计划缓存，因此可以重用。注意到，这里我使用的是“可靠”这个单词，而不是“快速”。即席查询有时候确实比存储过程执行得更好，
-- 但是它完全依赖执行计划被缓存的环境(“被发觉”的参数)，以及看你怎么测试、调优以及实现代码了。
-- 如果前面的这些理由还不能让你相信存储过程是非常好的，那么让我们再来看一下安全方面的好处。直接访问SQL Server实例和它的数据库的表(更坏的情况是访问sysadmin)会引起安全隐患。
-- 内联即席代码特别容易遭受SQL注入(injection)攻击。如果在T-SQL发送到SQL Server实例之前，有害的T-SQL就插入到了既有应用程序的T-SQL代码，那么就会发生SQL注入。除了SQL注入攻击，
-- 如果一些人得到了内联代码，他们就能收集数据库中基础架构的信息，从而指导他们尝试攻击。让所有SQL在存储过程内能保证只有存储过程被应用程序引用----而不是每一个列和表名。
-- 存储过程的另外一个安全方面的好处就是可以授予数据库用户和/或数据库角色对它们的访问而不是授予对表的直接访问权限。存储过程能作为控制层，
-- 你可以选择哪些列和行能被存储过程(和调用者)修改，哪些不能。
#13
[align=center]如果这条SQL语句比较长或者经常被调用的话，用存储过程会比较好。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。[/align]
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。[/align]
#14
如果这条SQL语句比较长或者经常被调用的话，用存储过程会比较好。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。
存储过程本身就有比较多的优点，比如：
1、可以更快的执行SQL语句
2、可以减少网络流量
这两个是比较看得见的，还有其他的就省略了。
如果SQL很多的话，存储过程效果就会很明显的。
#15
要的就是规范
#16
就是规定，遵守就行了。
其实坏处也是有的，将来某天换个oracle数据库，这些存储过程就基本废掉了。。。
其实坏处也是有的，将来某天换个oracle数据库，这些存储过程就基本废掉了。。。
#17
该回复于2011-02-23 09:14:30被版主删除
#18
那就看你这东西是不是要经常修改、