这是一个创建于 2132 天前的主题，其中的信息可能已经有所发展或是发生改变。
需求是这样的，每写入一条数据，需要读取过去的 N （ N<500 ）条数据进行重新计算并重新插入数据库，计算逻辑不复杂，就是加减乘除，尽可能支持并发高一些，什么语言更好一些，还是都可以？
第 1 条附言 · 2020 年 3 月 15 日
另外，考虑到开发效率+后期维护成本，哪个更好？
 |
1
kxjhlele 2020 年 3 月 15 日 via Android
直接 SQL 不行吗，merge
|
 |
3
keepeye 2020 年 3 月 15 日
这种情况下瓶颈不是在数据库么？
要选的话就 go 呗，可以支撑很大的并发，只要数据库能抗住 |
 |
4
opengps 2020 年 3 月 15 日
维护一个内存变量，存这 500 条数据应该占不了太多内存。真要落盘，那就多块 ssd
|
|
5
opengps 2020 年 3 月 15 日
SQL 数据库有个内存表，好像没有锁的问题，可以考虑拿来做中转罗盘
|
 |
6
refresh OP @keepeye 讲道理不会在数据库，统一读取之后，然后锁住用户，更新数据再统一插入。不过这样的方式内存占用肯定是多的了，而且如果是分布式的话，锁住用户也比较麻烦，可能需要维护一个公共锁。
|
 |
7
ericls 2020 年 3 月 15 日 via iPhone
我也觉得可以用 sql 做计算
|
|
10
refresh OP |
|
12
refresh OP @sujin190 用户可能只修改一条数据，但是有可能因为用户提交的其中一条数据，而需要修改所有的记录。举个例子，假如我现在有一个记帐系统，为用户提供两个功能：1. 每笔帐会有一个余额； 2. 会告诉用户总资产的变化。
那么每笔记录就需要做两个事情：1. 计算余额； 2. 计算总资产的变化。如果改动了中间一笔，那么后面的余额都会发生变化，且每天的总资产也会发生变化。 |
 |
13
sujin190 2020 年 3 月 16 日
@refresh #12 你举这个例子很不恰当，完全不符合现实情况，从现实来说，交易流水完全基于现实动作在时间维度产生，因为时间不可逆转，所以使资产或者余额发生变化的交易流水同样不可能存在需要修改的情况
如果因为某些情况之前的交易存在歧义或者错误而发送交易纠纷解决，那么既然现实已经在新的时间维度上真实发生了一件交易纠正的行为，那么就应该真实的产生一条新的交易记录从而使余额或者资产发生变更，修改原交易记录是极其不恰当而且也不符合现实的 关于系统异常导致的问题，下一条的交易变更应该完全基于上一条已提交完结的事务产生，在此种情况下不应该存在中间某条是错的情况 |
Select Language