【交流--数据层开发的技巧】
小弟，开发经验不足，希望向大家问一下实际开发中，底层开发的技巧
（这里所谓的底层是指三层中的数据层，牵涉到操作数据库的代码。）
现在的困惑：见很多软件后台牵涉到数据库的代码都是使用的存储过程，
小弟也知道存储过程有它的优势，
比如：
可以把程序代码和数据库操作代码分离，这样扩展能力更好；
在编写存储过程时，数据库就会对编写的存储过程进行分析；
......
问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中，
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句?
问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？
分不是问题，希望和大家交流！
我先说一下我的观点：
当然存储过程性能和效率上综合来说是比较高的，
但是当是简单的SQL语句还是没有必要使用存储过程的，
对于牵涉到数据的更改：增删改时或者语句比较复杂时首先考虑使用存储过程。
而对于见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中，
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
这种方式，我感觉也就没有体现出来存储过程的优势，和执行SQL语句也就没有太大区别了
[解决办法]
我的异常网推荐解决方案：oracle存储过程,http://www.myexception.cn/oracle-develop/177537.html
[解决办法]
存储过程为主
plain sql 为辅
基本的操作:增、删、改、查(select *)用存储过程
[解决办法]
当然存储过程性能和效率上综合来说是比较高的，
但是当是简单的SQL语句还是没有必要使用存储过程的，
对于牵涉到数据的更改：增删改时或者语句比较复杂时首先考虑使用存储过程。
同意你的这种看法，
当存储过程过多的时候，也不方便进行管理；
我一般是语句过长，或者参数太多，直接用sql语句或在传输上有影响或者是比较复杂的语句的时候才使用 存储过程。
其他的一般都是在程序中写sql语句，需要的地方传参
[解决办法]
你用的是MS SQL SERVER吧。我赞成2楼的看法。可以在大的批处理SQL脚本，比如事务之类的使用存储过程。
对于Oracle，对表的操作，基本都通过视图的方式。然后就是数据包，比SQL SERVER相对更复杂一些。但是这个是基本的应用模式，效率相对也比较高。
当然，应用与代码分离可以做到比较安全，比如即使入侵了Web，拿到了代码，也不能知道批处理事务的底层操作。
[解决办法]
其实，存储过程写在数据库，和写在程序中都是一样的
写在数据库中，也是通过存储过程名，去调用存储过程
写在程序中，直接到数据库中执行，感觉差不多。
简单的sql语句他很不安全，效率也低，所以尽量还是用存储过程
[解决办法]
存储过程
sql语句执行的时候要先编译，然后执行。存储过程就是编译好了的一些sql语句。应用程序需要用的时候直接调用就可以了，所以效率会高。
存储过程介绍
存储过程是由流控制和SQL语句书写的过程，这个过程经编译和优化后存储在数据库服务器中，应用程序使用时只要调用即可。在ORACLE中，若干个有联系的过程可以组合在一起构成程序包。
使用存储过程有以下的优点：
* 存储过程的能力大大增强了SQL语言的功能和灵活性。存储过程可以用流控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的 运算。
* 可保证数据的安全性和完整性。
# 通过存储过程可以使没有权限的用户在控制之下间接地存取数据库，从而保证数据的安全。
# 通过存储过程可以使相关的动作在一起发生，从而可以维护数据库的完整性。
* 再运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。 由于执行SQL语句的大部分工作已经完成，所以存储过程能以极快的速度执行。
* 可以降低网络的通信量。
* 使体现企业规则的运算程序放入数据库服务器中，以便：
# 集中控制。
# 当企业规则发生变化时在服务器中改变存储过程即可，无须修改任何应用程序。企业规则的特点是要经常变化，如果把体现企业规则的运算程序放入应用程序中，则当企业规则发生变化时，就需要修改应用程序工作量非常之大（修改、发行和安装应用程序）。如果把体现企业规则的 运算放入存储过程中，则当企业规则发生变化时，只要修改存储过程就可以了，应用程序无须任何变化。
数据库存储过程的实质就是部署在数据库端的一组定义代码以及SQL。
利用SQL的语言可以编写对于数据库访问的存储过程，其语法如下：
[ ]内的内容是可选项，而（）内的内容是必选项，
上面这个是网上摘过来的，但是说的可能还是清楚，就是说，一般的sql语句是可以写在程序里的。而存储过程是在数据库服务端的，是经过编译后的，只是调用。再者就是如果不分所以然，全部用存储过程，这样会给服务端很大压力，试想百万用户这样大的WEB站点，要有个几成用户同时访问，那挂定了，不对，可能有钱可以做得到，呵呵
[解决办法]
和LZ一样等待答案吧 在这块我也有相同的疑问
问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中，
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
难道还利于维护？
[解决办法]
可能有个适中原则，可能比较模糊，可以将复杂的，性能有要求的，或是特殊的当然还是存储过程，性能是比较好的。不管咋说，用存储过程没错，只要管理适当，只要在能力，安全，性能..范围内就用吧。利还是大于弊的。
[解决办法]
问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中，
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
存储过程的定义（或者说SQL语句）还是放到程序代码中没见过把定义也放程序里的，你说的是不是对临时表的操作或是动态执行exec（）的操作？
问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句?
得看维护交给数据库管理员还是程序员了。我做的C/S项目，除了无参数查询其余全用存储过程。
问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？
好的习惯就是代码标准化，其实数据层操作没什么特别之处啊
[解决办法]
发表一点想法
存储过程优点 执行效率高，这是优点
对于数据层的编写，尽量使用存储过程来代替基本的SQL语句，我觉得不是这样的
一般在算法不是很复杂的情况 我一般不用存储过程
还是据你项目的的架构，根据自己的具体项目情况去决定用什么，与自己写程序的风格也有关
[解决办法]
没感觉存储过程维护麻烦。
我是把所有的SQL语句都写进存储过程，然后把整个给保存成一个.sql文件。
需要修改的话，就打开.sql，修改，然后全选F5，感觉十分良好。
[解决办法]
个人见解：
如果都写成存储过程的话。。。
一个程序不一定只用一个数据库吧，
为了防止意外准备的备用服务器LZ应该了解吧
如果用存储过程的话，那么就得运行服务器上的数据库写准备一边
备用服务器上的数据库也需要准备一边
如有用户需要换新的备用服务器的话，还需要处理新服务器上的数据库里的各种存储过程。。。
虽然可以写成脚本，但是还是需要导一下
如果程序中用SQL就不用了吧。。。
[解决办法]
很简单...这是出于扩展性或可移植性的考虑...
SP的性能固然好但是SP不在SQL标准中，是属于DBMS的特性，因而各种DBMS的SP定义用法都不尽相同甚至还有完全不支持SP的...如果你的程序需要考虑兼容所有SQL标准数据库则SP可能会造成相当大的麻烦...
鉴于大多数需要操作数据库的程序都只限于特定或少数已知的DBMS，所以SP应用更广泛...但不能据此说谁更正确，因需求而定才是正理...
[解决办法]
复杂SQL语句 考虑存储过程、、
简单的增删改，就算了、
[解决办法]
其实还是参考应用。
简单操作直接sql语句。
如果复杂运算+处理还是调用sp方便。
oracle里就叫过程吧。sp是sql server的说法.
[解决办法]
存储过程只适应于组成较稳定的SQL语句，远不如程序拼接灵活。
说到执行效率，存储过程仅仅预编译，需求较灵活的情况下SQL拼接更容易按需取数(程序员追求程序效率更是如此)，更容易获得更高的效率。我们可以在程序中第一次执行某个SQL语句的时候自动生成相应存储过程(简单的SQL语句就没必要了)，可以说鱼与熊掌兼得。
存储过程的维护对于数据库管理员说简单了。对于需求较灵活的情况下修改SQL语句是常事，对于程序员来说就头大了，调试个程序还要与数据库管理员“同步”。
[解决办法]
存储过程优点和缺点也非常明显。
优点：
1、易维护。因为写在数据库中，修改后可直接生效。
2、天然支持事务，不用程序员考虑。
缺点：
1、正是由于它易维护，会导致系统容易由于小的修改，导致系统出问题。
2、移植性差。
3、对数据库压力大。由于数据库资源是非常宝贵的，数据库出问题将导致整个系统的所有使用人不能使用。
适中考虑。
不管是代码、SQL、还是存储过程。他们的执行效率相差不大。重要的是“代码”要优。如SQL、存储过程要用到重要索引；代码算法要优雅。
代码是运行在应用服务器上，而存储过程是在数据库上。所以存储过程多了对数据库压力会比较大。这个在设计时也要权衡考虑。
[解决办法]
一般有小项目就用sql吧，防止非法注入就OK了`不要杀鸡用牛刀啊`存储过程最后还是被编译成SQL语句的进行操作的`虽然安全，高效，但是消耗内存开支
[解决办法]
我比较喜欢使用存储过程，有时候维护时不需要修改代码，直接改一下存储过程就可以了!
[解决办法]
问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中，
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
如果你做的是项目是没区别,但如果你做的是产品呢.如果你做的产品能做到这样的效果:不依赖数据库代码,程序拷到那里,一启动程序,程序自己检查数据库部分是否存在、是否完整,不存在或不完整的自动调用程序创建,是不是很好?
问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句?
如果数据库的结构稳定（不会经常根据需求的变化更改已有的存储过程），当然首选存储过程，效率高些呀；（不过可以考虑存储过程由程序来执行）
问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？
如15楼所说，好的习惯就是代码标准化
[解决办法]
尽量使用存储过程实现,因为如果使用内嵌的SQL语句,造成数据访问量变大.比如一个查询语句.是把所有的数据量传到本地再进行查询操作的.最后也是只返回你需要的数据.而使用存储过程来做的话.只是返回你需要的数据,把一些逻辑计算与查询全部压给数据库服务器来做.来减轻客户端的负担.并且尽量少用游标,游标对数据库服务器的影响很大(大数据量),尽量不用*号,*号会严重增加数据库负担.如果不信你可以自己测试.很明显的.
[解决办法]
我的经验：
比较复杂的业务逻辑实现都可以使用存储过程，基本的增删改操作不要使用存储过程了。
一般一个操作要往2个或以上的数据库表中插入数据，就要考虑使用存储过程了
[解决办法]
上面有人说到存储过程多了会给服务器增大压力，但存储过程多跟服务器压力有什么关系呢？试想一下，同样的sql语句，写在代码里跟写在存储过程里，哪个给服务器造成的压力大呢?
[解决办法]
存储过程的缺点，为什么没有人谈呢？ 使用存储过程有安全隐患，很容易被别人copy过去了，别人拿着你的存储过程马上就能写出来一个新的东西，Copy你的，你到哪讲理去？
[解决办法]
也就.net版块会有这种需求写在SP里的吧。。JAVA版块大多数都说要把业务逻辑放到 应用程序中 不要放到SP里 说实话这个问题我也想很久了 一直也没想明白
看过大型系统里边的，感觉不是复杂的，实时性要求较高的，大多采用HIBERNATE这种ORM方式，而对于一些运算量高，实时性要求不大，计算或者逻辑复杂的，就都放到SP里边（如用户计费统计等）
说实话我心里挺喜欢放到SP里的，修改方便，调试也方便。但是许多大牛这个时候就会跳出来说这样不好，这样不利于维护，不利于移植，不OO，不。。。。
我也挺委屈的，但人家是大牛啊。我心里就在想，你们总说不利于移植。对，oracle太贵了，一个license要30W，大多数公司会考虑改为MYSQL，这个时候如果逻辑都是在SP里，要该为MYSQL，那会是非常痛苦的一件事。但要是放在HIBERNATE里了，配置文件改一下，基本上就能用了。看起来很完美是不是？
不过我这里倒想说一下，这本来不应该是程序员考虑的事！本来调研需求说好了做ORACLE的，现在改为MYSQL，当然就要付出代价了。用HIBERNATE看起来很爽很舒服一下子就解决问题了，但我想，举个例子，比方现在用JAVA写的程序，要换成C++，难倒您还能用HIBERNATE什么的不成？
好吧，我承认是我经验不到家，承认是我见识浅薄。这里我想告诉楼主，我曾经征询过多人这个问题，从教授到PM到大牛，给出的答案都是 业务逻辑不要写在SP里好 至于怎么个好法，说实话我现在并没有听到一个比较满意的答案。不过管他哪，就好像8岁到14岁我学的是0不是自然数，15岁了上初中了，人家老教授一个文件，0又变成自然数了，这有什么办法呢？还是一句话，能用就行。
