@adjusted #22 schema 并非单一真相,大多数的程序对接的存储介质并非一个,而程序却可以唯一(微服务场景下,每个服务原子化了),我倾向于,schema 做为底层,由程序自动化控制,在上线之后的生命周期中,不应该接触到 schema,而只能接触到程序,所以文档,图表均应该通过程序生成,而非 schema(schema 可以做为一个数据的来源,但不能做为直接源和单一源)

@zoharSoul #13
1.微服务导致数据库变多,sql 也就变多.
2.ci/cd 自动化(最起码开发环境下),数据库也是发版内容,也期望自动化.
3.团队合作,人员参差不齐,人员变动等,可能导致数据库版本的管理与服务版本混乱.

所以:
1.数据库版本控制自动化和标准化势在必行(起码是个趋势)

ps: 个人认为 model 只是一种对于数据库版本的表达而已.👀

优先级 过期策略 推送数量按时间(或者更多变量)控制

debian+docker

语言不是重点，你可以在拿一门语言来学习背后的知识，如：数据结构，算法（逻辑），操作系统。
当然如果你只是拿这个做跳板，那随意。

@javak #7 问题在于，如何不脱离社会，而工作是最简单的参与人类经济活动的方式之一。

很明显，这个是业务上，极有可能需要根据 channelType 的不同，在数据层面做更多的变化，而以前的设计可能针对 sms 这种渠道做了非常定制的操作，那么交付压力来了，未来有可能有问题，那怎么办才好呢？

而且这里的命名真的挺干净的，我喜欢这种

最简单地方式,就是做成点对点或者群组加密,只有网站和群组内成员才能阅读.

@THESDZ #127 顺带最重要的一点，能力都是需要持续演进的，掌握演进能力的能力，以及演进这种能力。

授人以鱼不如授人以渔，我仅从能力侧给你一些建议：
1.尽快形成自己的知识体系（网格化，层级化的），否则只有积累和堆砌，那基本没有帮助。
2.尽快形成适合自己学习的方式、方法。
3.不要对抗本能，要引导本能。
4.锻炼社交能力且不要失去社交的勇气。
5.自信来自实力，实力来自能力以及能力的使用。

1.生命周期
2.基于生命周期注册钩子函数，钩子运行使用命令模式（也可以是代理模式+适配器模式）

找一些自动同步（一键同步）的方式，或者网页端开箱即用的。

1.每天清洁脸部完成后做保湿；
2.买湿纸巾，常擦。

无脑选后端就好了，没什么难学的，你都考上硕士了，后端这点东西不难的。

我写代码,一般先写接口 /抽象类 /方法名,命名也很规范

而实现基本都交给 copilot
我的体验是: copilot 非常的好用!

版本?或者显示的状态标记?

@THESDZ #60 补充一个方式，做成既定事实，比如什么 买都买了之类的。

对方的核心诉求是什么？是话语权还是想沟通？
假如是话语权：
1.干脆一点，直接爆发，让对方明白双方平等；
2.装疯卖傻，阳奉阴违；
3.君子远庖厨，直接搬出去住。
假如是想多沟通：
1.主动沟通，控制话题。

增加配置从环境变量读取（或者启动参数）；
Docker 支持。