新开一贴：存储过程和直接在后台写数据访问代码之间的取舍~~~

Question

考虑到安全性和效率，现在操作数据我基本上都是用存储过程，但今天老板的一句话突然提醒了我---“怎么老是改数据库”。 
如果操作的数据有变化，就要到数据库改存储过程，而一般用户是不希望访问他的数据库的。 
如果把数据操作代码用拼接的方法直接写在后台，是不是就可以避免每次都去修改数据库里面的存储过程。 
大家有什么好的方法？或是折中的方案？说一下

Answer 1

QUOTE:不明白，用了SP反而不安全了？
--------------------
SQL语句暴露在DBMS之下,凡数据库管理人员就可以查看,修改等.

Answer 2

SQL语句暴露在DBMS之下,凡数据库管理人员就可以查看,修改等.
-----------------
暴汗~~~

Answer 3

QUOTE:其实使用存储过程有存储过程的好处，但也不需要任何操作都写在存储过程中的吧
------------------------------------------------
如果没有什么限制的话,还是以效率为上!

Answer 4

难道以前的SQL注入现在已经解决了？
并且解决方法不是存储过程(作为参数可以防止SQL注入)？

Answer 5

SQL语句暴露在DBMS之下,凡数据库管理人员就可以查看,修改等.
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－使用自己的Server与管理员，
找个诚信的管理员others，那就只能看RP了，即使不用sp,这种危险也不比使用低。

Answer 6

QUOTE:不明白，用了SP反而不安全了？ 
-------------------- 
SQL语句暴露在DBMS之下,凡数据库管理人员就可以查看,修改等.----------------------------------------------------
这个说法太汗了.  
一般dba分为管理dba和开发dba. 开发dba是在管理dba的许可内进行开发的.
这里不是说开发dba就是管理dba的下级, 而是指二者分工有不同. 哪些有不利于数据的稳定,安全等等,管理dba都会做出一些限制,这是他们的职责所在, 即开发dba所能实现的,只能在管理dba的许可下.
如果怕管理dba查看sp语句, 那这个就没有办法了. 你的整个数据库都在他手里,  真想弄你东西,他有啥干不了的.对于何处用语句,何处用存储过程, 从实现上讲个人觉得没有区别.当基于业务的一些操作和数据表的设计, 引起的比较费资源,或计算量(这里指业务的计算量,而非由于数据量大引起的底层计算量)大时,可以使用存储过程. 但是尽量不把业务逻辑封在过程里.
比如一些业务上的要求,从业务呈现来看,就是一类数据,但出于种种考滤, 数据表在设计时,被分开进行了设计, 这种情况下, 严重建议使用存储过程. 这样交给开发人员的是一个与数据表设计无关的东西. 而业务的重组也不会引起这种存储过程的变动.存储过程一定程度上有利于效率,(非动态语句的存储过程, 而且效率的提升是并不显著, 因为与直接写语句比执行的都还是一样,虽然很多情况下省去了编译时间) 但不便于管理和维护.  想想中小企业有几家有专职dba的.
理论学的不好,可能说的不清楚. 能说明多少算多少吧.

Answer 7

谢谢fcuandy 
受益匪浅！！！

Answer 8

简单的语句一般写写语句就OK了,如果复杂点的建议用过程，具体可以参考以下几种情况：
1、过程的初衷是为了减少客户端与服务端的数据流,提高效率,使能够在服务端就能完成的操作直接处理完了再返回结果.
2、过程相对于程序来说,它是静态的,你没法像程序那么结构化(不是说结构化SQL阿,别钻空子哦),一个好的结构可以在少数几个方法中用到,但是一个好的函数可以在很多地方使用.
3、对于通过过程就能够实现的返回,规范的做法应该用过程来实现,比如我有一个批量复制记录并做相应的修改的过程,如果用程序来实现就消耗太多,而如果我在复制的过程需要对每个记录关联的表中对应的字段做不同的更新要用到过程的话,可能效率上会有所提高,出错几率却会大大地提高,这个是没有必要的.
4、对于那些过程和语句都能够实现的，如果有好的处理机制，建议用语句好了，中小型的工程有多少过程又是经典的呢。我们公司用的一套cs系统那个软件公司开发了五年了，那个数据要是放出来可能这里很多人都要笑得喘不过气来，别人的效益还是不错的，前两天去他们公司，开发组大大小小老老少少十几个人呐。
所以，建议楼主还是习惯怎么写就怎么写，把时间和精力放到实际应用中来吧，一切的开发都是以应用为目标的，不要耽误了工期哦，呵呵。