所以，要和产品去确认有没有查看签到历史这个需求，有的话是看几天。如果无限的话，就只能一条条记录了。如果是看一周，那你搞 7 个字段存就是了。总之，能不存记录就不存记录。记录无限增长，实在是太可怕了。

随便看，但我表示自己只能看看而已……

要什么签到记录表，都是垃圾数据。每个用户记一个签到时间、连签天数、累计天数就行了，签到时间为空或早于今天 0 点就能签到，否则就是已签到。

楼主你们有设计师直接出图就行了，还要什么产品做原型。

微服务也可以很简单。一个最简单的微服务，就是注册中心+配置中心+网关而已。需要写额外的代码吗？不需要！都是 pom 引入一个包，然后启动类一个注解，配置文件几行配置就完事。最后就是需要在配置中心分别对每个服务做一下配置。就这点事情，百度一下最多 1 天功夫就搞定了，压根没有什么难度好吧。

你这个需求无法优化数据结构，肯定快不起来的……

具体到顾问，on 后面加上 and a. adviser_id = 顾问 id 就行

select q.* from question q left join answer a on a. question_id = q.id where a.id is null;

@hijoker 关节痛。痛风是尿酸在关节处形成微小的结石，相当于在关节的缝隙里面撒了一把沙子。无时无刻不在磨砂子，这滋味就很销魂。

微服务可以搞，k8s 没必要。

楼上说小团队搞不来微服务的，我表示我一个人就搞起来了。根本没什么难度，开发反而更简单了。

公司里面还有偷外卖的啊，我一直以为这个事情只发生在学校里面呢。

@KeroZhai 那么字段怎么对应呢？搞个 map 传进去么？有写这个 map 的美国功夫，我 new 一个目标对象出来手动 set 一下就完了。

序列化+反序列化就完了，要什么自行车

@wszgrcy 肯定是油条泡一下豆浆再吃啊🐶

坐标杭州，家里舍不得电费没开空调，翻出来一条毛毯把脚包起来。公司里面有中央空调，就不需要了。

不建议这么做。我都是按功能先分 C 端 B 端，然后分大模块，再分小模块把包分好。最后在小模块里面建 xxxController/xxxService/xxxServiceImpl 这么 3 个文件。好处是层次分明，找文件非常方便。而且以后要拆分服务也很方便，整个包复制到新项目后老项目里面删掉就行了，不需要到处找文件。

福报厂似乎不卡学历

显示器接 MacBook，然后在 MacBook 上面通过远程桌面 /ssh 操作台式机。

NoSQL 当然是在应该用的时候用。MongoDB 我们用来存快照数据，其他的使用场景也基本就没了。。