存储过程的使用场景(什么是soa roa 谈谈两种技术的原理及适用场景)
本文目录
- 什么是soa roa 谈谈两种技术的原理及适用场景
- 最近几天一直在搞Mybatis调用存储过程的问题,用
- sql 存储过程 游标用在什么地方(新手刚学,不知道使用场景)我是C#做Web开发的
- 存储过程的变量指什么
- 为什么在mysql存储过程中创建的临时表不能
- 在开发过程中,到底要不要使用存储过程
什么是soa roa 谈谈两种技术的原理及适用场景
本真REST当然是对面向资源架构的一种实现,而并非一种纯粹的技术决策。所以当讨论本真REST时,真正应该讨论的问题是:其基础支撑——面向资源的架构(ROA)——是否真的适合作为你的SOA实现。为正确评估该问题,让我们首先回想一下SOA的架构风格,它是基于企业业务架构的功能性分解,并且引入了两个高层次的抽象:企业业务服务和业务流程。企业业务服务代表的是现有IT能力(和企业的业务功能相一致)。业务流程编排业务服务,并定义业务的整体功能。而REST是一组被称之为面向资源架构(ROA)的架构准则。ROA构建在资源这一概念之上;每个资源都是一个能够直接访问的分布式组件,可通过一个标准的、通用的接口来处理。所以,面向资源的架构(ROA)其最根本的还是一种基于资源的分解。为了评估本真REST是否适用于面向SOA的实现,我们真正需要回答的问题是,“服务和资源之间到底是什么关系?”服务 vs. 资源何为服务?在最简单的情况下,服务可以被定义为一个自包含、独立开发、可部署、可管理和可维护的软件实现,它从整体上为企业提供特定的与业务相关的功能,并且在设计上是“可集成的”。“服务”可以通过动词(verb)来定义(例如,“验证客户信用积分”,这描述了服务实现的业务功能)。服务并不是某个编程结构或一组APIs,而是一个用于实现企业解决方案的架构(设计单元、实现以及维护)和部署构件。服务接口(尤其对某个给定的服务而言)定义服务功能,并且可由多种方式实现。存在两种基本的定义服务接口的方法——RPC风格和消息(messaging)风格,RPC风格实现使用服务调用语义并且通过服务接口中的一组参数来定义。而消息风格的服务接口被有效地固定(本质上只需要进行“执行”操作)使用XML文档作为输入和输出(这和GoF设计模式非常相似)。在这种情况下,服务语义是由输入和输出消息的语义来确定。过去,服务通常被定义为一组方法的集合,但正如参考文献,但作为整体它们共享同一个命名空间,这样简化了对服务的管理。何为资源?在最简单的情况下,资源可以被定义为一个可直接访问的、独立开发的、可部署的、可管理的和可维护的软件构件,它支持特定的数据。资源可以通过名词(noun)来定义,比如“医生的预约”就描述了资源提供的数据。某一资源也可以和其他资源相关联并为它们提供引用(链接)。实际上,一个资源就类似于一个对象,不过它是带有预定义(CRUD)接口语义的对象。REST中的语义基于HTTP操作集,如下所示:createResource——创建一个新的资源(以及相应的唯一标示)– PUTgetResourceRepresentation——获取资源信息– GETdeleteResource ——删除资源(可选地包括相关联的资源)– DELETE(只是引用的资源),POST(当需要删除相关联的资源时使用)modifyResource——更改资源— POSTgetMetaInforatmion——取得资源元数据信息—HEAD资源通过两部分定义:资源URL和资源所提供的所有操作上定义的输入/输出参数。这和服务不同,服务的方法之间是完全独立,并且能够以独立端点(endpoints)的方式部署,而资源上的方法遵循OO语义,这意味着所有的方法(除createResource以外)都必须依附于底层的某个资源(同一个URL)。资源和服务之间的根本差异基于上述对资源和服务的定义,凭直觉它们显然是不同的。我们先继续深究这些差别,然后再讨论它们是如何对最终架构产生影响的。正如文献中描述的:REST不仅不是面向服务的,相反,面向服务和REST风马牛不相及文献中进一步阐明了二者之间的区别:如果把WS-*比作是互联网世界的RPC,那么REST就是互联网世界的数据库管理系统(DBMS)……传统的基于SOA的集成表现了不同软件构件之间通过各种过程或方法进行交互。REST有效地将每个软件构件看作一组数据库表,而这些构件之间使用SELECT, INSERT, UPDATE和DELETE来通信。(或如你所想的使用GET, PUT, POST, DELETE)。那业务逻辑放在哪里呢?在存储过程中?不太对,其实在触发器中。这里我们用J2EE打个稍微不太恰当的比方。我们把服务想象成无状态会话bean,而资源想象成实体bean。服务(或会话beans)作为控制器控制执行所需的操作,不管底层是哪个资源。打个比方,某个支出账户服务可能会用到账户ID、支出金额和支出所需账户。这样的服务可以支出任何现有账户。资源(或实体bean)充当数据访问机制,其面对给定数据类型的某一实例。比如,为了从某一账户支出,需要先找到这一账户相关的信息,然后才能更新它,从而向所需账户进行支出。另外提醒一下,与能实现任意所需的方法的实体bean不同的是,一个REST资源只有一个更改资源的方法。这意味着真实的业务操作——支出——只能编码成消息请求的一部分。
最近几天一直在搞Mybatis调用存储过程的问题,用
ibatis:sql需要自己写hibernate:sql自动生成上面是最大的区别,下面是一些细节.选择Hibernate还是iBATIS都有它的道理:Hibernate的特点:Hibernate功能强大,数据库无关性好,O/R映射能力强,如果你对Hibernate相当精通,而且对Hibernate进行了适当的封装,那么你的项目整个持久层代码会相当简单,需要写的代码很少,开发速度很快,非常爽。以数据库字段一一对应映射得到的PO和Hibernte这种对象化映射得到的PO是截然不同的,本质区别在于这种PO是扁平化的,不像Hibernate映射的PO是可以表达立体的对象继承,聚合等等关系的,这将会直接影响到你的整个软件系统的设计思路。Hibernate对数据库结构提供了较为完整的封装,Hibernate的O/R Mapping实现了POJO 和数据库表之间的映射,以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系,即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握, Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的SQL 并调用JDBC 接口加以执行。Hibernate的缺点就是学习门槛不低,要精通门槛更高,而且怎么设计O/R映射,在性能和对象模型之间如何权衡取得平衡,以及怎样用好Hibernate方面需要你的经验和能力都很强才行,但是Hibernate现在已经是主流O/R Mapping框架,从文档的丰富性,产品的完善性,版本的开发速度都要强于iBATIS。iBATIS的特点:iBATIS入门简单,即学即用,提供了数据库查询的自动对象绑定功能,而且延续了很好的SQL使用经验,对于没有那么高的对象模型要求的项目来说,相当完美。iBATIS的缺点就是框架还是比较简陋,功能尚有缺失,虽然简化了数据绑定代码,但是整个底层数据库查询实际还是要自己写的,工作量也比较大,而且不太容易适应快速数据库修改。当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。对于实际的开发进行的比较:1. iBATIS需要手写sql语句,也可以生成一部分,Hibernate则基本上可以自动生成,偶尔会写一些Hql。同样的需求,iBATIS的工作量比 Hibernate要大很多。类似的,如果涉及到数据库字段的修改,Hibernate修改的地方很少,而iBATIS要把那些sql mapping的地方一一修改。2. iBatis 可以进行细粒度的优化比如说我有一个表,这个表有几个或者几十个字段,我需要更新其中的一个字段,iBatis 很简单,执行一个sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的话就比较麻烦了,缺省的情况下 hibernate 会更新所有字段。 当然我记得 hibernate 有一个选项可以控制只保存修改过的字段,但是我不太确定这个功能的负面效果。例如:我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据库读很多数据,节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...一般情况下Hibernate 会把所有的字段都选出来。比如说有一个上面表有8个字段,其中有一两个比较大的字段,varchar(255)/text。上面的场景中我为什么要把他们也选出来呢?用hibernate 的话,你又不能把这两个不需要的字段设置为lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出ibatis 的好处了。如果我需要更新一条记录(一个对象),如果使用 hibernate,需要现把对象 select 出来,然后再做 update。这对数据库来说就是两条sql。而iBatis只需要一条update的sql就可以了。减少一次与数据库的交互,对于性能的提升是非常重要。3. 开发方面:开发效率上,我觉得两者应该差不多。可维护性方面,我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保sql/hql。相对Hibernate“O/R”而言,iBATIS 是一种“Sql Mapping”的ORM实现。 而iBATIS 的着力点,则在于POJO 与SQL之间的映射关系。也就是说,iBATIS并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写,然后通过映射配置文件,将SQL所需的参数,以及返回的结果字段映射到指定POJO。使用iBATIS 提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,这一层与通过Hibernate 实现ORM 而言基本一致,而对于具体的数据操作,Hibernate会自动生成SQL 语句,而iBATIS 则要求开发者编写具体的SQL 语句。相对Hibernate而言,iBATIS 以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间。4. 运行效率在不考虑 cache 的情况下,iBatis 应该会比hibernate 快一些或者很多。 上面是hibernate和ibatis的区别。现在说一说对于手写sql和存储过程的支持:这些东西其实我们都不需要担心,这种框架能被大家接受就说明像这种功能那是必须的,一定要支持,否肯定被人扣板砖!hibernate对手写sql和存储过程都有很好的支持,对于手写sql有的时候还是有必要的,如对于非常复杂的sql语句,可能对于我们用hql语句是很难完成的,这个时候就需要我们用sql来完成,相对于hql,我们还是比较熟练sql的!存储过程的支持也是必要的,和只需简单的一句:CallableStatement cstmt = con.prepareCall(procedure); 就能对已有存储过程的调用。ibatis这我就不多少了,一样,都有很好的支持。存在就有其合理性,对于不同的情况,我们会有不同的解决方案,所以不要轻易的说那个那个功能不好,没准他就是你解决难题的杀手锏!
sql 存储过程 游标用在什么地方(新手刚学,不知道使用场景)我是C#做Web开发的
web开发很多用orm框架,存储过程和游标都很少用。比如你用EF提倡CodeFirst,这得看你框架的规则上进行。纯粹来讲所有的sql执行语句都可以放到存储过程里。比如insert,uodate,delete,select都可以。存储过程有执行速度快的优势,参数传递占用空间小。同时方便后期修改和管理。比如像我现在用的一个简单的存储过程,返回当前客户期数:create proc proc_name(@account nvarchar(30)) asbegin/*------------------------------------------------------------------------------------- 程序说明:返回当前客户的期初数,业务结算月为26,以打印时间为准 BY:ChuiFeng 2013-02-27 返回结果:@CreditAmount字段-------------------------------------------------------------------------------------*/ declare @ARAmount decimal(22,10) = 0 --已经收到的客户金额, 实收金额 declare @SaleAmount decimal(22,10) = 0 --货物金额, 应收金额 --declare @amount decimal(22,10) =0 --存放期初 declare @endDate datetime --截止日期 --构造截止日期 if(DATEPART(DAY, GETDATE())》26) --当前日期超过结算日26号 set @endDate = CAST(CAST(DATEPART(year, GETDATE()) AS varchar(4)) + ’-’ + CAST(DATEPART(MONTH, GETDATE()) AS nvarchar(2)) + ’-26’ AS DateTime) else set @endDate = CAST(CAST(DATEPART(year, GETDATE()) AS varchar(4)) + ’-’ + CAST(DATEPART(MONTH, GETDATE())-1 AS nvarchar(2)) + ’-26’ AS DateTime) select @ARAmount=SUM(Amount) from T_AR where CusCode=@account and PrintState=255 and DATEDIFF(DAY,PrintedTime,@endDate)》0 --select @SaleAmount=SUM(Amount) from T_SOs where SONO in (select SONO from T_SO where CusCode=@account and PrintState=255 and DATEDIFF(DAY,PrintedTime,@endDate)》0) select @SaleAmount=SUM(Amount) from T_SO where CusCode=@account and PrintState=255 and DATEDIFF(DAY,PrintedTime,@endDate)》0 if(@ARAmount is null) set @ARAmount=0 if(@SaleAmount is null) set @SaleAmount=0 return @SaleAmount-@ARAmount end如果客户需求发生了变化比如结算日改了,那么我们只需要修改存储过程就行了 而不必要修改程序代码重新编译。至于游标:建议慎用 少用。主要就是性能问题。一般是在大数据量循环的情况下可能用但是最好别用,用好的存储过程可以实现就别用游标...
存储过程的变量指什么
存储过程是面向对象的数据库编程语言,与其他面向对象编程语言类似,可声明变量,用变量来存取某一类值,变量在存储过程中占有非常重要的位置。变量声明在MySQL语言的存储过程中,变量有会话变量、存储过程变量两种。两种变量的声明方式不同,作用场景也不尽相同,在实际使用中要根据需要加以选择。
1.变量种类((1)会话变量会话变量也称用户变量,可以在一个客户端会话的任何地方声明,作用域是整个会话,会话断开后,会话变量也就消失。会话变量名以@开头,使用set直接赋值,在一个会话内,会话变量只需初始化一次。
例如,Set@num=1;表示声明了一个名字叫“@num”的会话变量,其初始值为1。
(2)存储过程变量存储过程变量以DECLARE为关键字声明的变量,只能在存储过程中使用,其命名不需要以@开头。以DECLARE声明的变量都会被初始化为NULL,存储过程变量存在于数据库服务器上。2.变量定义存储过程变量定义格式:DECLARE+变量名+数据类型+其中,((1)DECLARE为声明存储过程变量的关键字;
(2)变量名可以任意,但尽可能达到能表意的目的;
(3)数据类型为MySQL的数据类型,如int
为什么在mysql存储过程中创建的临时表不能
提到MySQL临时表,我们都很熟悉了,一般来说,分为两类:
1. MySQL 临时表引擎,名字叫做 Memory。比如
create table tmp1(id int, str1 varchar(100) ) engine = memory;
由参数max_heap_table_size 来控制,超过报错。
2. 非临时表的引擎,这里又分为两类:
用户自定义的临时表,比如:
- create temporary table (id int, str1 varchar(100) );
SQL执行过程中产生的内部临时表,比如:UNION , 聚合类ORDER BY,派生表,大对象字段的查询,子查询或者半连接的固化等等场景。
- mysql》 show status like ’%tmp_%tables%’;``+-------------------------+-------+``| Variable_name | Value |``+-------------------------+-------+``| Created_tmp_disk_tables | 0 |``| Created_tmp_tables | 0 |``+-------------------------+-------+``2 rows in set (0.00 sec)
VARCHAR的变长存储。那就是如果临时表的字段定义是 VARCHAR(200),那么映射到内存里处理的字段变为CHAR(200)。假设 VARCHAR(200) 就存里一个字符 "Y", 那岂不是很大的浪费。
大对象的默认磁盘存储,比如 TEXT,BLOB, JSON等,不管里面存放了啥,直接转化为磁盘存储。
- mysql》 SELECT * FROM performance_schema. memory_summary_global_by_event_name WHERE event_name like ’%temptable%’G*************************** 1. row *************************** EVENT_NAME: **memory/temptable/physical_disk** COUNT_ALLOC: 0 COUNT_FREE: 0 SUM_NUMBER_OF_BYTES_ALLOC: 0 SUM_NUMBER_OF_BYTES_FREE: 0 LOW_COUNT_USED: 0 CURRENT_COUNT_USED: 0 HIGH_COUNT_USED: 0 LOW_NUMBER_OF_BYTES_USED: 0CURRENT_NUMBER_OF_BYTES_USED: 0 HIGH_NUMBER_OF_BYTES_USED: 0*************************** 2. row *************************** EVENT_NAME: **memory/temptable/physical_ram** COUNT_ALLOC: 1 COUNT_FREE: 0 SUM_NUMBER_OF_BYTES_ALLOC: 1048576 SUM_NUMBER_OF_BYTES_FREE: 0 LOW_COUNT_USED: 0 CURRENT_COUNT_USED: 1 HIGH_COUNT_USED: 1 LOW_NUMBER_OF_BYTES_USED: 0CURRENT_NUMBER_OF_BYTES_USED: 1048576 HIGH_NUMBER_OF_BYTES_USED: 10485762 rows in set (0.03 sec)
默认内部临时表引擎。
支持变长字符类型的实际存储。
设置变量 temp_table_max_ram 来控制实际存储内存区域大小。
那么这两种临时表的计数器通常用 show global status like ’%tmp_%tables%’ 来查看。比如
以上结果分别代表,只创建磁盘上的临时表计数以及临时表的总计数。这两个计数器由参数 tmp_table_size 和 max_heap_table_size 两个取最小值来控制。
那在 MySQL 5.7 之前,这个 SQL 运行中产生的临时表是 MYISAM,而且只能是 MYISAM。那 MySQL 从 5.7 开始提供了参数 Internal_tmp_mem_storage_engine 来定义内部的临时表引擎,可选值为 MYISAM 和 INNODB 。当然这里我们选择 INNODB 。并且把内部的临时表默认保存在临时表空间 ibtmp1 (可以用参数 innodb_temp_data_file_path 设置大小以及步长等)下。当然这里我们得控制下 ibtmp1 的大小,要不然一个烂SQL就把磁盘整爆了。
但是MySQL 5.7 之前都没有解决如下问题:
MySQL 8.0 开始,专门实现了一个临时表的引擎 TempTable , 解决了 VARCHAR字段的边长存储以及大对象的内存存储。由变量 interal_tmp_mem_storage_engine来控制,可选值为 TempTable(默认)和 Memory;新引擎的大小由参数temp_table_max_ram 来控制,默认为1G。超过了则存储在磁盘上(ibtmp1)。并且计数器由性能字典的表 memory_summary_global_by_event_name 来存储。
以上 memory/temptable/physical_disk 代表放入磁盘上的临时表计数情况。
memory/temptable/physical_ram 代表放入内存的临时表计数情况。
那总结下MySQL 8.0 引入的 TempTable 引擎:
在开发过程中,到底要不要使用存储过程
对于普通的应用场景, 推荐是不要是用存储过程的但是如果数据处理过程比较繁琐复杂, 尤其是牵扯到很多表的交叉查询及更新的时候, 存储过程还是首选