【交流--数据层开发的技巧】

Question

小弟，开发经验不足，希望向大家问一下实际开发中，底层开发的技巧 
（这里所谓的底层是指三层中的数据层，牵涉到操作数据库的代码。） 现在的困惑：见很多软件后台牵涉到数据库的代码都是使用的存储过程， 
小弟也知道存储过程有它的优势， 
比如： 
可以把程序代码和数据库操作代码分离，这样扩展能力更好； 
在编写存储过程时，数据库就会对编写的存储过程进行分析； 
...... 问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中， 
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？ 问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句? 问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？ 分不是问题，希望和大家交流！
我先说一下我的观点： 
当然存储过程性能和效率上综合来说是比较高的， 
但是当是简单的SQL语句还是没有必要使用存储过程的， 
对于牵涉到数据的更改：增删改时或者语句比较复杂时首先考虑使用存储过程。 而对于见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中， 
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？ 
这种方式，我感觉也就没有体现出来存储过程的优势，和执行SQL语句也就没有太大区别了 

Answer 1

存储过程为主
plain sql 为辅基本的操作:增、删、改、查(select *)用存储过程

Answer 2

当然存储过程性能和效率上综合来说是比较高的， 
但是当是简单的SQL语句还是没有必要使用存储过程的， 
对于牵涉到数据的更改：增删改时或者语句比较复杂时首先考虑使用存储过程。同意你的这种看法，
当存储过程过多的时候，也不方便进行管理；
我一般是语句过长，或者参数太多，直接用sql语句或在传输上有影响或者是比较复杂的语句的时候才使用 存储过程。
其他的一般都是在程序中写sql语句，需要的地方传参

Answer 3

你用的是MS SQL SERVER吧。我赞成2楼的看法。可以在大的批处理SQL脚本，比如事务之类的使用存储过程。对于Oracle，对表的操作，基本都通过视图的方式。然后就是数据包，比SQL SERVER相对更复杂一些。但是这个是基本的应用模式，效率相对也比较高。当然，应用与代码分离可以做到比较安全，比如即使入侵了Web，拿到了代码，也不能知道批处理事务的底层操作。

Answer 4

呵呵，是MS SQL SERVER，小弟最近在做.Net方面开发

Answer 5

其实，存储过程写在数据库，和写在程序中都是一样的
写在数据库中，也是通过存储过程名，去调用存储过程
写在程序中，直接到数据库中执行，感觉差不多。简单的sql语句他很不安全，效率也低，所以尽量还是用存储过程

Answer 6

存储过程 
sql语句执行的时候要先编译，然后执行。存储过程就是编译好了的一些sql语句。应用程序需要用的时候直接调用就可以了，所以效率会高。 
存储过程介绍 
存储过程是由流控制和SQL语句书写的过程，这个过程经编译和优化后存储在数据库服务器中，应用程序使用时只要调用即可。在ORACLE中，若干个有联系的过程可以组合在一起构成程序包。 
使用存储过程有以下的优点： 
* 存储过程的能力大大增强了SQL语言的功能和灵活性。存储过程可以用流控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的 运算。 
* 可保证数据的安全性和完整性。 
# 通过存储过程可以使没有权限的用户在控制之下间接地存取数据库，从而保证数据的安全。# 通过存储过程可以使相关的动作在一起发生，从而可以维护数据库的完整性。 
* 再运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。 由于执行SQL语句的大部分工作已经完成，所以存储过程能以极快的速度执行。 * 可以降低网络的通信量。 
* 使体现企业规则的运算程序放入数据库服务器中，以便： 
# 集中控制。 
# 当企业规则发生变化时在服务器中改变存储过程即可，无须修改任何应用程序。企业规则的特点是要经常变化，如果把体现企业规则的运算程序放入应用程序中，则当企业规则发生变化时，就需要修改应用程序工作量非常之大（修改、发行和安装应用程序）。如果把体现企业规则的 运算放入存储过程中，则当企业规则发生变化时，只要修改存储过程就可以了，应用程序无须任何变化。 数据库存储过程的实质就是部署在数据库端的一组定义代码以及SQL。 利用SQL的语言可以编写对于数据库访问的存储过程，其语法如下： 
[code]CREATE PROC[EDURE] procedure_name [;number] 
[ 
{@parameter data_type} ][VARYING] [= default] [OUTPUT] 
] 
[,...n] 
[WITH　
{ 
RECOMPILE　
| ENCRYPTION　
| RECOMPILE, ENCRYPTION 
} 
] 
[FOR REPLICATION] 
AS 
sql_statement [...n][/code]
[ ]内的内容是可选项，而（）内的内容是必选项，
上面这个是网上摘过来的，但是说的可能还是清楚，就是说，一般的sql语句是可以写在程序里的。而存储过程是在数据库服务端的，是经过编译后的，只是调用。再者就是如果不分所以然，全部用存储过程，这样会给服务端很大压力，试想百万用户这样大的WEB站点，要有个几成用户同时访问，那挂定了，不对，可能有钱可以做得到，呵呵

Answer 7

和LZ一样等待答案吧    在这块我也有相同的疑问  问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中， 
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？
难道还利于维护？ 

Answer 8

来学习学习
我觉得数据量大，sql语句复杂的时候才用存储过程
反之就直接sql

Answer 9

看完了所有的文字。存储过程是写在sql脚本里还是写在页面中呢

Answer 10

问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中， 
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？ 存储过程的定义（或者说SQL语句）还是放到程序代码中没见过把定义也放程序里的，你说的是不是对临时表的操作或是动态执行exec（）的操作？
问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句? 得看维护交给数据库管理员还是程序员了。我做的C/S项目，除了无参数查询其余全用存储过程。
问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？ 
好的习惯就是代码标准化，其实数据层操作没什么特别之处啊 

Answer 11

发表一点想法存储过程优点 执行效率高，这是优点对于数据层的编写，尽量使用存储过程来代替基本的SQL语句，我觉得不是这样的
一般在算法不是很复杂的情况 我一般不用存储过程还是据你项目的的架构，根据自己的具体项目情况去决定用什么，与自己写程序的风格也有关

Answer 12

谢谢15楼朋友的回答，很受用
对于问题一，我说的“存储过程的定义（或者说SQL语句）还是放到程序代码中”意思是创建存储过程的SQL语句也放在程序代码中

Answer 13

没感觉存储过程维护麻烦。我是把所有的SQL语句都写进存储过程，然后把整个给保存成一个.sql文件。需要修改的话，就打开.sql，修改，然后全选F5，感觉十分良好。

Answer 14

个人见解：
如果都写成存储过程的话
一个程序不一定只用一个数据库吧，
为了防止意外准备的备用服务器LZ应该了解吧
如果用存储过程的话，那么就得运行服务器上的数据库写准备一边
备用服务器上的数据库也需要准备一边
如有用户需要换新的备用服务器的话，还需要处理新服务器上的数据库里的各种存储过程
虽然可以写成脚本，但是还是需要导一下
如果程序中用SQL就不用了吧

Answer 15

很简单...这是出于扩展性或可移植性的考虑...SP的性能固然好但是SP不在SQL标准中，是属于DBMS的特性，因而各种DBMS的SP定义用法都不尽相同甚至还有完全不支持SP的...如果你的程序需要考虑兼容所有SQL标准数据库则SP可能会造成相当大的麻烦...鉴于大多数需要操作数据库的程序都只限于特定或少数已知的DBMS，所以SP应用更广泛...但不能据此说谁更正确，因需求而定才是正理...

Answer 16

复杂SQL语句 考虑存储过程、、简单的增删改，就算了、

Answer 17

一般都是在sql脚本里
2楼正解 

Answer 18

其实还是参考应用。
简单操作直接sql语句。
如果复杂运算+处理还是调用sp方便。oracle里就叫过程吧。sp是sql server的说法.

Answer 19

存储过程只适应于组成较稳定的SQL语句，远不如程序拼接灵活。
说到执行效率，存储过程仅仅预编译，需求较灵活的情况下SQL拼接更容易按需取数(程序员追求程序效率更是如此)，更容易获得更高的效率。我们可以在程序中第一次执行某个SQL语句的时候自动生成相应存储过程(简单的SQL语句就没必要了)，可以说鱼与熊掌兼得。
存储过程的维护对于数据库管理员说简单了。对于需求较灵活的情况下修改SQL语句是常事，对于程序员来说就头大了，调试个程序还要与数据库管理员“同步”。

Answer 20

像我们这样的小公司基本上都不用存储过程，都是sql 语句，当然效率也不高了。存储过程我还不会呢？

Answer 21

存储过程优点和缺点也非常明显。优点：
1、易维护。因为写在数据库中，修改后可直接生效。
2、天然支持事务，不用程序员考虑。缺点：
1、正是由于它易维护，会导致系统容易由于小的修改，导致系统出问题。
2、移植性差。
3、对数据库压力大。由于数据库资源是非常宝贵的，数据库出问题将导致整个系统的所有使用人不能使用。适中考虑。不管是代码、SQL、还是存储过程。他们的执行效率相差不大。重要的是“代码”要优。如SQL、存储过程要用到重要索引；代码算法要优雅。代码是运行在应用服务器上，而存储过程是在数据库上。所以存储过程多了对数据库压力会比较大。这个在设计时也要权衡考虑。

Answer 22

一般有小项目就用sql吧，防止非法注入就OK了`不要杀鸡用牛刀啊`存储过程最后还是被编译成SQL语句的进行操作的`虽然安全，高效，但是消耗内存开支

Answer 23

问题1：我也见到很多开发人员把存储过程的定义（或者说SQL语句）还是放到程序代码中， 
而没有放到数据库中定义，这和SQL语句执行有什么差别，执行性能上又有什么差别？ 
如果你做的是项目是没区别,但如果你做的是产品呢.如果你做的产品能做到这样的效果:不依赖数据库代码,程序拷到那里,一启动程序,程序自己检查数据库部分是否存在、是否完整,不存在或不完整的自动调用程序创建,是不是很好?问题2：是不是对于数据层的编写，尽量使用存储过程来代替基本的SQL语句? 
如果数据库的结构稳定（不会经常根据需求的变化更改已有的存储过程），当然首选存储过程，效率高些呀；（不过可以考虑存储过程由程序来执行）问题3：不知道大家在开发中，对数据层操作数据库代码的编写有什么好的习惯？ 
如15楼所说，好的习惯就是代码标准化

Answer 24

尽量使用存储过程实现,因为如果使用内嵌的SQL语句,造成数据访问量变大.比如一个查询语句.是把所有的数据量传到本地再进行查询操作的.最后也是只返回你需要的数据.而使用存储过程来做的话.只是返回你需要的数据,把一些逻辑计算与查询全部压给数据库服务器来做.来减轻客户端的负担.并且尽量少用游标,游标对数据库服务器的影响很大(大数据量),尽量不用*号,*号会严重增加数据库负担.如果不信你可以自己测试.很明显的.

Answer 25

sql 和存储过程差不多 除非你是很大的项目 你才能看出差别 存储过程效率要比sql语句效率高些 

Answer 26

兄弟帮宣传一下
http://stockstar.com/
证券之星，上海，世纪大道
招.Net Web开发程序员20人，本科。 
5k以下主要看态度，5k以上的主要看高性能大并发经验，10k以上要看运气了。 
 简历发至
 [email protected]

Answer 27

上面有人说到存储过程多了会给服务器增大压力，但存储过程多跟服务器压力有什么关系呢？试想一下，同样的sql语句，写在代码里跟写在存储过程里，哪个给服务器造成的压力大呢?

Answer 28

存储过程的缺点，为什么没有人谈呢？ 使用存储过程有安全隐患，很容易被别人copy过去了，别人拿着你的存储过程马上就能写出来一个新的东西，Copy你的，你到哪讲理去？

Answer 29

都说存储过程效率高。如果是简单的操作，存储过程比SQL语句效率不会高到哪去。参数多、sql语句太长、复杂考虑用存储过程。考虑sql注入攻击用存储过程。用SQL的话要过滤一下。

Answer 30

也就.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又变成自然数了，这有什么办法呢？还是一句话，能用就行。

Answer 31

我还是比较喜欢用存储过程的，即使是一条简单的查询语句。我觉得不但维护起来比较方便，而且还比较安全。另外，借LZ宝地顺便问一下，大家经常用视图吗？如果是6-7个表做表连接，用视图好还是直接多表连接好呢？
——————————————————————————————————————————
OLAP的话 用视图 加索引 速度很快的 不过使用视图要小心 毕竟视图相当于 固化的SQL ，使用不当 比如 视图与视图的连接 就有可能降低效率

Answer 32

如果你的程序是纯数据库程序，而且数据不需要给爱他程序共享
如果你将来确实没有改变DBMS的需要，
把业务逻辑写到存储过程里未尝不可
而且你要把所有的逻辑都放在数据库里to 93楼 sniffer12345：
非纯数据库程序
不把业务逻辑放在数据库端，除了你说的不易维护，不利于移植等以外
还有可伸缩性不知道你想过没有？
数据库一般情况下是只能有一个的，
却可能有多个程序在使用，其中可能有大量并发程序
实际上数据库服务器的CPU资源是极其珍贵的，
数据库服务器的瓶颈一般是CPU，而不是内存、磁盘、网络
如果数据库本身承担大量计算任务，当大量并发访问来到时，会马上瘫痪的而应用程序本身不存在唯一性，
应用程序的容错与负载均衡甚至可以分布在很多很多台应用程序服务器上
当数据库只作为存储的功能来使用时，就可以大大减轻其压力
这也是HIBERNATE这种貌似很繁琐的东西能够大行其道的原因
当对象映射到数据库表时，不要说存储过程，甚至表连接这种复杂的SQL语句都免了~