好比手机号嘛, 按号段先分配给不同的运营商, 运营商再卖给个人.

另起一个服务, 目前的服务每次向新的服务申请若干连续的优惠券(申请记录在一张新表里面, 请求比较少, 可以不用 redis), 用完了再申请.

@MozzieW #19 还需要 1.5 秒吗, 这个数据量应该不需要吧.
你原来的 sql 里面的 group by 是放在最后的, 应该不需要:

select ... from
(select DISTINCT uid from log where createdAt > '2021-10-01 00:00:00') as logged
join ....

用日志表 log 去 join user, 然后再 join order

日志表先找到最近 10 天登录的用户, 这样数据少很多

N 年前, 我用的第一代还是第二代 iPad. 麦克风坏了, 因为有一个角被磕破了半个花生大小的伤口, 找了苹果直营, 第三方维修, 都不给修. 理由是我们不单修麦克风, 要换整个外壳和主板, 但是外壳被人为弄坏了, 所以要 2000 多. 最后拉扯了几次, 作罢.

别怪第三方, 苹果也这样.

行业几乎都是这么干的, 不这么干的就赚不到钱.

可以用摩拜单车到现在的美团单车的每一代产品的图片来做例子. 比上面的图 1 图 2 好的多.

MVP 是为了验证产品核心需求, 是否是用户需要的, 是否可行.

站在未来看现在, 才知道现在做的 MVP 是否浪费. 我觉得 MVP 应该是从功能的角度来看.

但是图 1 没有说服力. 这里罗列的产品并不是演化的关系, 它们都是满足不同场景的用户需求.

"一个客户可能被多个员工负责而且会变。
所以没有办法存员工 id "

按说即使是多个员工负责, 也不会超过 10 个吧? 拼接多个员工 id 存在一个字段, 用 like 应该可以.

如果觉得效率低, 可以把员工 id 分组, 比如用 4 个字段存负责的销售 id: sales00, sales01, sales02, sales03, 按照 id%4 分别存储(hash 更好).

sales00 => #100#,#104#
sales01 => #101#
sales02 => #1002#,#1006#
sales03 =>

现在查询员工 1002 的客户的明细:
select * from trades where sales02 like '%#1002#%'

如果这个员工的需求是有意义的, 那么最好是弄个 job, 每天把全公司的交易明细都处理一遍, 分员工出报表, 不需要做数据库的 IN 查询.

有点意思, 有点像 Dreamweaver, 拖拽式生成界面. "代码库"这个名字有点误导.

因为 jwt 省钱, 省事.

1) sessionId 的有效验证必须依赖后端查询, jwt 是通过计算来验证, 成本低, 速度快.
2) jwt 可以添加一些不敏感的数据, 前后端都可以使用, 减少了查询, 成本低.

sessionId 更安全, 但是有多少数据需要这么安全呢？ 而且需要高安全性的数据和操作可以要求用户提供其他凭证的, 比如支付时提供密码之类.

@kop1989 #17
@yangyaofei #18
感谢

@yangyaofei #11 "刹车根据踩踏行程，分配动能回收和刹车比例", 所以就是其实技术上是可以做到的. 谢谢

@opengps #10 我的意思是保持比较轻的刹车的时候, 动能回收. 不是遇到紧急情况需要快速减速的场景.

@billlee #8 看网友的说法, 发动机制动应该减速效果没这个强. 不过我没对比过.

@kop1989 #6 "电制动和物理制动的匹配问题" 是说要结合电制动和物理制动这两个制动方式, 协调工作比较有难度的意思吗?

@263 #1 你这混动吧? 没啥不好意思的, 我没开过混动. 你也别不好意思

"会不会和同事的关系发生疏远"
会. 所以要定期沟通; 及时给同事反馈.


远程比坐班的优点多多, 所以我觉得这点劣势没啥, 不会让人焦虑.