无法准确评估时间, 这个有复盘是什么原因评估错误吗? 因为需求不明确, 使用了新技术, 新工具, 需求的难度远超开发者的能力? 如果没有原因, 也不排除是被迫评估了一个领导希望的时间.

记了 4 年了. 主要是了解钱用在哪里, 顺带也节省了一些开支.

@oh 哦。 我帖子里面就说了啊, 开始的时候找过一些在线服务来着, sheet2api, sheetsu 等等.

@txoooy 这个只是提供查询功能的, 相当于一个数据表.

@oh 广告么?

🙏

5 公里我可以跑 50 分钟

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

另起一个服务, 目前的服务每次向新的服务申请若干连续的优惠券(申请记录在一张新表里面, 请求比较少, 可以不用 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 更安全, 但是有多少数据需要这么安全呢？ 而且需要高安全性的数据和操作可以要求用户提供其他凭证的, 比如支付时提供密码之类.