sql server把退款总金额拆分到尽量少的多个订单中详解

一、问题

原来有三个充值订单,现在要退款450元,如何分配才能让本次退款涉及的充值订单数量最少?具体数据参考下图:

二、解决方案

Step 1:对可退金额进行降序排列,以便优先使用可退金额比较大的订单

Step 2:使用CTE公用表达式,实现类似for或while循环或游标的功能

三、脚本

create table #t
(
  充值 int,
  已退 int,
  可退 int
)
insert into #t(充值, 已退, 可退)
values (200, 100, 100), (500, 200, 300), (300, 100, 200)

/*
作者:zhang502219048
脚本来源:https://www.cnblogs.com/zhang502219048/p/14127208.html
*/

declare @i要退 int = 450;
with cte1 as
(
  select *, row_number() over(order by 可退 desc) rn, 0 可发起退款, 0 待退
  from #t
),
cte2 as
(
  select rn, 充值, 已退, 可退,
    可发起退款 = case when @i要退 > 可退 then 可退 else @i要退 end,
    待退 = @i要退 - case when @i要退 > 可退 then 可退 else @i要退 end -- 待退 = 要退 - 可发起退款
  from cte1
  where rn = 1
  union all
  select t2.rn, t2.充值, t2.已退, t2.可退,
    可发起退款 = case when t1.待退 > t2.可退 then t2.可退 else t1.待退 end,
    待退 = t1.待退 - case when t1.待退 > t2.可退 then t2.可退 else t1.待退 end
  from cte1 t2
  inner join cte2 t1 on t1.rn = t2.rn - 1 -- t2是t1的下一条记录
  --where t2.rn > 1 and t1.待退 > 0
)
select * from cte2

drop table #t

四、脚本运行结果

总结

到此这篇关于sql server把退款总金额拆分到尽量少的多个订单中的文章就介绍到这了,更多相关sql server退款总金额拆分到订单内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • sql server把退款总金额拆分到尽量少的多个订单中详解

    一.问题 原来有三个充值订单,现在要退款450元,如何分配才能让本次退款涉及的充值订单数量最少?具体数据参考下图: 二.解决方案 Step 1:对可退金额进行降序排列,以便优先使用可退金额比较大的订单 Step 2:使用CTE公用表达式,实现类似for或while循环或游标的功能 三.脚本 create table #t ( 充值 int, 已退 int, 可退 int ) insert into #t(充值, 已退, 可退) values (200, 100, 100), (500, 200,

  • SQL Server统计信息更新时采样百分比对数据预估准确性的影响详解

    为什么要写统计信息 最近看到园子里有人写统计信息,楼主也来凑热闹. 话说经常做数据库的,尤其是做开发的或者优化的,统计信息造成的性能问题应该说是司空见惯. 当然解决办法也并非一成不变,"一招鲜吃遍天"的做法已经行不通了(题外话:整个时代不都是这样子吗) 当然,还是那句话,既然写了就不能太俗套,写点不一样的,本文通过分析一个类似实际案例来解读统计信息的更新的相关问题. 对于实际问题,不但要解决问题,更重要的是要从理论上深入分析,才能更好地驾驭数据库. 何时更新统计信息 (1)查询执行缓慢

  • 在android开发中尽量不要使用中文路径的问题详解

    在开发过程中发现,有些软件对中文路径支持不大好,如果使用Uri.fromFile转换中文路径为uri的时候,有些软件可能会识别不出来导致功能异常,已知的有两个应用:1.腾讯微博的分享功能:2.酷派D530下调用系统摄像头拍照. 如果非要用中文路径,可以采用下面的方式: String path = getCameraTempFilePath(),; //有些系统摄像头对中文路径支持不好,通过Uri.fromFile编码之后反而有问题,先手动加上吧 //                 Uri ur

  • SQL Server优化50法汇总

    查询速度慢的原因很多,常见如下几种:1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2.I/O吞吐量小,形成了瓶颈效应.3.没有创建计算列导致查询不优化.4.内存不足5.网络速度慢6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8.sp_lock, sp_who, 活动的用户查看,原因是读写竞争资源.9.返回了不必要的行和列 10.查询语句不好,没有优化可以通过如下方法来优化查询 :1.把数据.日

  • SQL Server学习笔记之事务、锁定、阻塞、死锁用法详解

    本文实例讲述了SQL Server学习笔记之事务.锁定.阻塞.死锁用法.分享给大家供大家参考,具体如下: 1.事务 隐式事务 /*================================================================== 当以create,drop, fetch,open, revoke,grand, alter table,select,insert,delete,update,truncate table 语句首先执行的时候,SQL Server会话

  • sql语句优化之SQL Server(详细整理)

    MS SQL Server查询优化方法 查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,

  • SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区

    本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

  • SQL Server中的SQL语句优化与效率问题

    很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解.比如: select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan' 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那

  • SQL Server 全文搜索功能介绍

    SQL Server 的全文搜索(Full-Text Search)是基于分词的文本检索功能,依赖于全文索引.全文索引不同于传统的平衡树(B-Tree)索引和列存储索引,它是由数据表构成的,称作倒转索引(Invert Index),存储分词和行的唯一键的映射关系.倒转索引是在创建全文索引或更新全文索引时,由SQL Server自动创建和维护的.全文索引主要包含三种分析器:分词器(Word Breaker).词干分析器(stemmer)和同义词分析器.全文索引中存储的数据是分词及其位置等信息,分词

  • SQL Server实现全文搜索查询详解

    目录 一.概述 二.全文搜索查询 三.将全文搜索查询与 LIKE 谓词进行比较 四.全文搜索体系结构 4.1.SQL Server 进程 4.2.过滤器守护程序主机进程 五.全文搜索处理 5.1.全文索引过程 5.2.全文查询流程 六.全文索引体系结构 6.1.全文索引结构 6.2.全文索引片段 6.3.全文索引和常规 SQL Server 索引之间的差异 总结 一.概述 全文索引在表中包括一个或多个基于字符的列.这些列可以具有以下任何数据类型:char.varchar.nchar.nvarch

随机推荐