看到别人做项目时总是用到存储过程和视图,可为什么我总是想不起来在哪里要用到他们。
存储过程可以减少数据库连接次数,视图是在频繁的查询和权限控制时会用到。对这此感到不解。我在做例子项目时为什么一次也用不到。也想不到。
打了比方吧。有A表和B表两个表,业务逻辑是要先查询A表中的flag字段,如果flag=true,那么用户可以再更新B表数据,否则返回错误,说不可更新。
像这种业务逻辑,我一般是在代码码调用两个方法,先调A表的查询方法返回一个Flag,如果是true,则再调用B的更新方法,类似这样:String flag = A.findFlag();
if(flag==true){
    B.update(name,password); 
}else{
     system.out.println(“flag is false,you can't update the B!”);
}但是根据网上的说法,在这里是不是就应该用存储过程了?也是就是写一个存储过程来做这个业务,如proIsFlag(flag,name,password),然后在方法里只要调用这个存储过程就可以?
这样的话与前面的方法相比,只打开一次数据库连接,而且存储过程只需要一次编译,速度也还行?
还有就是当大家在处理业务逻辑时,是大多用的存储过程实现呢,还是通过代码逻辑多次调用数据库不同表之间的查询方法实现呢?

小弟很费解啊想不明白了,再次就是视图的使用条件和使用方法,有经验的大大们指点一下小弟吧,在此谢谢了!
J2EE版也发了一样的贴。。

解决方案 »

  1.   

    存储过程(Stored Procedure)是一组为了完成特定功能的SQL语句集,是利用SQL Server所提供的Transact-SQL语言所编写的程序。经编译后存储在数据库中。存储过程是数据库中的一个重要对象,用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。存储过程是由流控制和SQL语句书写的过程,这个过程经编译和优化后存储在数据库服务器中,存储过程可由应用程序通过一个调用来执行,而且允许用户声明变量 。同时,存储过程可以接收和输出参数、返回执行存储过程的状态值,也可以嵌套调用。优点
      * 存储过程的能力大大增强了SQL语言的功能和灵活性。存储过程可以用流控制语句编写,有很强的灵活性,可以完成复杂的判断和较复杂的 运算。   * 可保证数据的安全性和完整性。   # 通过存储过程可以使没有权限的用户在控制之下间接地存取数据库,从而保证数据的安全。   # 通过存储过程可以使相关的动作在一起发生,从而可以维护数据库的完整性。   * 在运行存储过程前,数据库已对其进行了语法和句法分析,并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。由于执行SQL语句的大部分工作已经完成,所以存储过程能以极快的速度执行。   * 可以降低网络的通信量。   * 使体现企业规则的运算程序放入数据库服务器中,以便:   # 集中控制。   # 当企业规则发生变化时在服务器中改变存储过程即可,无须修改任何应用程序。企业规则的特点是要经常变化,如果把体现企业规则的运算程序放入应用程序中,则当企业规则发生变化时,就需要修改应用程序工作量非常之大(修改、发行和安装应用程序)。如果把体现企业规则的运算放入存储过程中,则当企业规则发生变化时,只要修改存储过程就可以了,应用程序无须任何变化。   简单讲:   1.存储过程只在创造时进行编译,以后每次执行存储过程都不需再重新编译,而一般SQL语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。   2.当对数据库进行复杂操作时(如对多个表进行Update,Insert,Query,Delete时),可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。   3.存储过程可以重复使用,可减少数据库开发人员的工作量   4.安全性高,可设定只有某些用户才具有对指定存储过程的使用权
    编辑本段缺点
      1:调试麻烦,但是用 PL/SQL Developer 调试很方便!弥补这个缺点。   2:移植问题,数据库端代码当然是与数据库相关的。但是如果是做工程型项目,基本不存在移植问题。   3:重新编译问题,因为后端代码是运行前编译的,如果带有引用关系的对象发生改变时,受影响的存储过程、包将需要重新编译(不过也可以设置成运行时刻自动编译)。   4: 如果在一个程序系统中大量的使用存储过程,到程序交付使用的时候随着用户需求的增加会导致数据结构的变化,接着就是系统的相关问题了,最后如果用户想维护该系统可以说是很难很难、而且代价是空前的,维护起来更麻烦。

    视图的含义
      从用户角度来看,一个视图是从一个特定的角度来查看数据库中的数据。从数据库系统内部来看,一个视图是由SELECT语句组成的查询定义的虚拟表。从数据库系统内部来看,视图是由一张或多张表中的数据组成的,从数据库系统外部来看,视图就如同一张表一样,对表能够进行的一般操作都可以应用于视图,例如查询,插入,修改,删除操作等。   视图是一个虚拟表,其内容由查询定义。同真实的表一样,视图包含一系列带有名称的列和行数据。但是,视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表,并且在引用视图时动态生成。对其中所引用的基础表来说,视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表,或者其它视图。分布式查询也可用于定义使用多个异类源数据的视图。   视图是存储在数据库中的查询的SQL 语句,它主要出于两种原因:安全原因, 视图可以隐藏一些数据,如:社会保险基金表,可以用视图只显示姓名,地址,而不显示社会保险号和工资数等,另一原因是可使复杂的查询易于理解和使用。   视图:查看图形或文档的方式。   视图一经定义便存储在数据库中,与其相对应的数据并没有像表那样又在数据库中再存储一份,通过视图看到的数据只是存放在基本表中的数据。对视图的操作与对表的操作一样,可以对其进行查询、修改(有一定的限制)、删除。   当对通过视图看到的数据进行修改时,相应的基本表的数据也要发生变化,同时,若基本表的数据发生变化,则这种变化也可以自动地反映到视图中。
    视图的作用
      * 简单性。看到的就是需要的。视图不仅可以简化用户对数据的理解,也可以简化他们的操作。那些被经常使用的查询可以被定义为视图,从而使得用户不必为以后的操作每次指定全部的条件。   * 安全性。通过视图用户只能查询和修改他们所能见到的数据。数据库中的其它数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上,但不能授权到数据库特定行和特定的列上。通过视图,用户可以被限制在数据的不同子集上:   使用权限可被限制在基表的行的子集上。 使用权限可被限制在基表的列的子集上。 使用权限可被限制在基表的行和列的子集上。 使用权限可被限制在多个基表的连接所限定的行上。 使用权限可被限制在基表中的数据的统计汇总上。 使用权限可被限制在另一视图的一个子集上,或是一些视图和基表合并后的子集上。   * 逻辑数据独立性。视图可帮助用户屏蔽真实表结构变化带来的影响。
    视图的优点
      视图有很多优点,主要表现在:   •视点集中   •简化操作   •定制数据   •合并分割数据   •安全性   1. 视点集中   视图集中即是使用户只关心它感兴趣的某些特定数据和他们所负责的特定任务。这样通过只允许用户看到视图中所定义的数据而不是视图引用表中的数据而提高了数据的安全性。   2. 简化操作   视图大大简化了用户对数据的操作。因为在定义视图时,若视图本身就是一个复杂查询的结果集,这样在每一次执行相同的查询时,不必重新写这些复杂的查询语句,只要一条简单的查询视图语句即可。可见视图向用户隐藏了表与表之间的复杂的连接操作。   3. 定制数据   视图能够实现让不同的用户以不同的方式看到不同或相同的数据集。因此,当有许多不同水平的用户共用同一数据库时,这显得极为重要。   4. 合并分割数据   在有些情况下,由于表中数据量太大,故在表的设计时常将表进行水平分割或垂直分割,但表的结构的变化却对应用程序产生不良的影响。如果使用视图就可以重新保持原有的结构关系,从而使外模式保持不变,原有的应用程序仍可以通过视图来重载数据。   5. 安全性   视图可以作为一种安全机制。通过视图用户只能查看和修改他们所能看到的数据。其它数据库或表既不可见也不可以访问。如果某一用户想要访问视图的结果集,必须授予其访问权限。视图所引用表的访问权限与视图权限的设置互不影响。
    视图的安全性
      视图的安全性可以防止未授权用户查看特定的行或列,是用户只能看到表中特定行的方法如下:   1 在表中增加一个标志用户名的列;   2 建立视图,是用户只能看到标有自己用户名的行;   3 把视图授权给其他用户。
    逻辑数据独立性
      视图可以使应用程序和数据库表在一定程度上独立。如果没有视图,应用一定是建立在表上的。有了视图之后,程序可以建立在视图之上,从而程序与数据库表被视图分割开来。视图可以在以下几个方面使程序与数据独立:   1 如果应用建立在数据库表上,当数据库表发生变化时,可以在表上建立视图,通过视图屏蔽表的变化,从而应用程序可以不动。   2 如果应用建立在数据库表上,当应用发生变化时,可以在表上建立视图,通过视图屏蔽应用的变化,从而使数据库表不动。   3 如果应用建立在视图上,当数据库表发生变化时,可以在表上修改视图,通过视图屏蔽表的变化,从而应用程序可以不动。   4 如果应用建立在视图上,当应用发生变化时,可以在表上修改视图,通过视图屏蔽应用的变化,从而数据库可以不动。
      

  2.   

    未必非要用,mysql从5才开始支持存储过程,请百度视图和存储过程的优势
      

  3.   

    但是根据网上的说法,在这里是不是就应该用存储过程了?也是就是写一个存储过程来做这个业务,如proIsFlag(flag,name,password),然后在方法里只要调用这个存储过程就可以?
    这样的话与前面的方法相比,只打开一次数据库连接,而且存储过程只需要一次编译,速度也还行?
    这个说法是正确的,你的程序和数据库的交互只是一次,然后的判断更新则在数据库中执行存储过程来解决。由于不需要把数据传回你的程序,所以速度上肯定会快。但存储过程只需要编译一次,并不是每次连接后使用都需要重新编译。 只要不修改存储过程的代码,那数据库系统就不会重新编译它。还有就是当大家在处理业务逻辑时,是大多用的存储过程实现呢,还是通过代码逻辑多次调用数据库不同表之间的查询方法实现呢?
    这个要看个人习惯和开发项目组的要求。
    各有优缺点。 用存储过程实现,显然程序上简单,速度上会快。
    但缺点也很明显,
    1)就是不同的数据库的存储过程的语言风格,显然不统一,当从SQL SERVER移植到ORACLE的时候你需要重写所有存储过程。
    2)开发一个项目,需要有人写数据库存储过程,有人写程序代码,毕竟找一个又懂ORACLE PL/SQL又写C#代码的毕竟比仅会写C#要难一些。
    3)设计的原则上,数据库应该仅起数据存储层的作用,不应该去参与业务逻辑层。
      

  4.   

    我还是用存储过程不多。基本都不用。。都是通过业务逻辑java代码实现。多表操作都是调用多个查询方法,习惯了