把aggregated value 存在一个DB column vs live aggregation

overiams 发表于 2025-04-02 07:31:08
谢谢。请问cleanup 这里指什么？意思是写入的时候总归还是要额外做一次calculation？

比如dump这个record去history table。这样这个table永远都是可以再act的user了，每次都是fullscan。

t__c___ 发表于 2025-4-3 04:15
比如dump这个record去history table。这样这个table永远都是可以再act的user了，每次都是fullscan。

哦哦，也有道理。
我当时想的是如果已经有一个类似action_count的 column，我们至少就完全不用在这个API里考虑这个history table了。
但确实是同时也可以down size 这个history table，如果它没有别的用处的话。

overiams 发表于 2025-4-2 23:42
我也是醉了。我要是面试官，对你的评价是不知道clarify requirements，没有辩证思维，混淆概念。

首先 ...

哥，不要生气，我知道在美国找工作不容易，容易心情不好。

没办法，你帖子里没说只能认为你面试的时候也没提。

你和面试官提了分页他还问你O（n）不O（n）？这个有点奇怪啊。要是分页了O（n）又怎么样，一页不就那几个数据。

关于lock和事务的化，一般还是精确一点比较好。储蓄是投资理财，但是不是所有投资理财都是储蓄。事务一般是利用锁来实现的，但是不是所有的锁都是事务。面试官可能会问你到底是什么锁，也可能不会问。

补充内容 (2025-04-03 18:57 +08:00):

不对啊，我感觉被坑了，第二种方法怎么就o n了，第二种方法有索引的话，一查索引就知道需要返回的user ids了，然后分页一个个读就可以了，没有o n啊

123都没有的话就用乐观锁呗。这个不需要任何db orm的feature，或者用个check什么的。方法2应该是比1要好点吧，但也看场景 如果是actjon两次以后就不能加了 那显然好很多，如果没有这个限制，写入自然会变得更昂贵