- 主题:健康宝核酸天数改规则
是不是天数这个字段没存库啊
改的这么随意，刷了老数据，还要统一规则
如果存库了，完全可以老数据老规则，新数据新规则，平滑过渡一下，几天就行了
- 来自 水木社区APP v3.5.5
--
FROM 223.104.42.*
这种事
哪里轮得到底层技术背锅……
上峰存心想做的话，回溯一年数据算天数都不是问题
【 在 hothail 的大作中提到: 】
: 是不是天数这个字段没存库啊
: 改的这么随意，刷了老数据，还要统一规则
: 如果存库了，完全可以老数据老规则，新数据新规则，平滑过渡一下，几天就行了
: ...................
--
FROM 103.40.221.*
上峰意思不是技术问题
咱们就研究技术
何况技术支持了，才能给提供方案，否则也白扯
- 来自 水木社区APP v3.5.5
【 在 javafish 的大作中提到: 】
: 这种事
: 哪里轮得到底层技术背锅……
:
: 上峰存心想做的话，回溯一年数据算天数都不是问题
--
FROM 223.104.42.*
据北京日报客户端消息，2日下午，北京市经信局对健康宝核酸检测天数计算规则调整进行说明：6月29日、6月30日、7月1日三天中0-6时出具核酸检测结果的用户，仍按老办法呈现核酸检测天数，直至有新的核酸检测结果覆盖。目前，健康宝后台已展开对上述3日相关时段的检测天数的批量调整，并将尽快完成调整。对于7月2日及以后进行采样的，将按照新的核酸检测天数计算规则计算。
--
FROM 223.104.42.*
天数存字段？每天凌晨自动更新一次？显然不可能这么设计
【 在 hothail 的大作中提到: 】
: 是不是天数这个字段没存库啊
: 改的这么随意，刷了老数据，还要统一规则
: 如果存库了，完全可以老数据老规则，新数据新规则，平滑过渡一下，几天就行了
: ...................
--
FROM 114.253.33.*
存个交易日期很easy啦，然后各种花式算时长也很easy啦。
而且正常情况就是采样接收审核上传各个时间点都存着的，那帮眼高手低的[屏蔽字]们没事还要考核啥数据完整性有效性及时性呢。
但是那帮眼高手低的[屏蔽字]们就是能想出千奇百怪的方案来，做为技术你也只能捏着鼻子按照他们的奇怪想法实施。
【 在 hothail 的大作中提到: 】
: 是不是天数这个字段没存库啊
: 改的这么随意，刷了老数据，还要统一规则
: 如果存库了，完全可以老数据老规则，新数据新规则，平滑过渡一下，几天就行了
: ...................
--
FROM 36.24.191.*
每天凌晨更新，应该不会这样，
我猜大概率还是由请求触发的更新，一个是健康宝客户端的请求，和医院上传核酸结果的请求 然后触发的。
健康宝客户端还限制了刷新的频率，
- 来自 水木社区APP v3.5.5
【 在 roy 的大作中提到: 】
: 天数存字段？每天凌晨自动更新一次？显然不可能这么设计
--
FROM 120.244.218.*
有个数据库字段还是有可能的
基于触发就才更新设想，
可以先算db的数据保存到cache中
或者反过来
先算cache，在持久化到db，感觉都有可能
当然没有这个字段也可能，都在内存里
- 来自 水木社区APP v3.5.5
【 在 roy 的大作中提到: 】
: 天数存字段？每天凌晨自动更新一次？显然不可能这么设计
--
FROM 120.244.218.*
这种玩意前台js里算都轻轻松松，反正关键时间点都存着。
【 在 hothail 的大作中提到: 】
: 每天凌晨更新，应该不会这样，
: 我猜大概率还是由请求触发的更新，一个是健康宝客户端的请求，和医院上传核酸结果的请求 然后触发的。
: 健康宝客户端还限制了刷新的频率，
: ...................
--
FROM 36.24.191.*
抛开政策问题，码农按你这么设计也要被鄙视啊
天数这种东西存数据库，每天所有人都得更新一遍，纯浪费资源，而且0点后还会出现不一致
肯定是只存个检测时间，显示的时候按规则计算啊，一样可以做到旧数据旧规则，新数据新规则
【 在 hothail 的大作中提到: 】
: 是不是天数这个字段没存库啊
: 改的这么随意，刷了老数据，还要统一规则
: 如果存库了，完全可以老数据老规则，新数据新规则，平滑过渡一下，几天就行了
: ...................
--
FROM 124.126.0.*