数据库 这样递减的 sql 怎么写

tomnia · 2018年12月30日 · 最后由 darkbaby123 回复于 2019年01月05日 · 833 次阅读

表 A 有数据:

id n
1 100
2 150
3 120

表 B 有数据:

id m
1 80
2 200

最后的查询结果是:也就是说表 A 和 B 分别以 id 为升序,表 B 的 m 从表 A 的 n 中消耗,最后查询的结果是这个消耗的过程。

id d
1 80
1 20
2 150
3 30
共收到 20 条回复

表 B 的 m 从表 A 的 n 中消耗

不懂什么意思,能换个方式阐述吗?

luikore 回复

m被n分解,d就是被分解的序列,所以d的和等于m的和 不知道这样表达清楚一些没

是说 A 的 id 是主键,B 的 id 是 A 的外键。然后 n 是初始值,m 是每次 action 的消耗。d 返回经过每次消耗后的剩余的集合?

dsh0416 回复

A 和 B 的 id 都不是主键或外键,只是用以表示A 和 B消耗的顺序,用 id 让人误解了。你后面的理解是对的

tomnia 回复

还是没懂,你要不要列一下计算过程

dsh0416 回复

m 80(id=1) 从 n 里的100(id=1)消耗 80(生成 d 的第一条记录),m 80消耗完。m 200(id=2) 从 n 的 20(id=1,100 消耗了 80 的剩余,生成 d 的第二条记录),m 剩下 180 从 n 150(id=2)消耗 150(生成 d 的第三条记录),m 剩下 30 从 n 120 里消耗 30(生成 d 的第四条记录)m 200消耗完。

tomnia 回复

这样的查询适合单独存一张表吧,否则的话,每次做一定是扫全表,时间复杂度是 O(n+m),放在数据库里做好像没有什么意义啊。

dsh0416 回复

我也有想过把这个计算结果再放一张表里。但表 B 的数据插入顺序不一定与计算的顺序(表 B 的 id)一致,这就导致了有时候表 B 一条记录的插入,这个计算结果表里存在大量的更新,最坏的情况也许是整张表数据的重建,这怎么玩?

tomnia 回复

这个基本上和财务数据的逻辑是一致的,是一个类似单向(qu)链(kuai)表(lian)的结构。中间有一个节点变化,至少会引起之后所有的数据都必须要重算。最坏的情况是变更第一个值,就不得不触发全表重建。

把A B表全查出来用代码来处理呗

escyezi 回复

你是正经的吗?😂

tomnia 回复

这样肯定比你从数据库各种Join得到的结果快的多,毕竟O(m+n). 要不只能写过程了,像写ruby代码一样在sql里遍历一遍。。。

weito 回复

很少手写的代码能比join快的

翻完评论才看明白什么意思。我觉得这个计算逻辑不适合用 SQL 做,因为它的关注点并非在集合,而在集合中的每条元素。用两个链表做计算(递归比较头节点)反而更容易,计算结果再保存进数据库就行。

如果有非常特殊的原因一定要在 SQL 里实现,可以看一下 lateral join 和 with recursive 。

tomnia 回复

这种需求强行要用SQL查询解决的你,是正经的吗?🙃

darkbaby123 回复

还是33是个正经人

计算用程序,别用数据库。

darkbaby123 回复

其实这个问题看了评论后第一直觉就是用一个计算结果表去解决,但是用计算结果表可能让解决这个问题变得烦琐起来,因为计算结果表的数据与表B里数据的顺序有关,表B数据的计算顺序又不一定与产生顺序一致。这就导致要维护计算结果表数据的正确性,需要做很多事情,我目前想到的有:表B插入一条数据后,要向计算表里插入若干条结果数据(也可能同时需要删除更多旧的不正确的数据);也许这个计算过程还没结束,表B又插入了一条数据呢?...诸如此类的。 所以我想这可能是题主选择用sql解决这个问题的原因,这样可能比较省事(如果这样的sql写得出来)

@wootaw 是的,如果按照 LZ 的计算过程描述,其实是有不少中间数据的,比较过程化,这并声明式的 SQL 适合表达的领域。而且如果不考虑存储因素的话化,这个需求本质上就是一个链表计算。因此把计算过程和存储分开思考,解决方案的适用性会广很多。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册