严肃的场景下，可以考虑设置 AuthorizedKeysFile none 关闭用户主目录里的 authorized_keys ，并设置 AuthorizedKeysCommand 到中心服务器（比如 LDAP ）去查询用户的 authorized_keys 项，在 LDAP 里给用户开个自己编辑的权限……不过这个配置还是挺复杂的，让用户自己编辑也多少有点复杂。

默认情况下只能到逐台服务器逐个用户扫描了。

国内这个安卓是阉卓

你需要系统地学习 Linux 服务器知识…

你是不是对 PLT 的学术界有什么误解……

go 的错误处理硬生生把本该用 sum type 来做的事（ either ok result or error info ）做成了 product type （ a tuple with both ok result and error info ）……哪个学术界是这么玩的？

肉存

“三十多岁升副处”……你确定吗？你是不是对副处有什么误解。

这就是阿里

贵司真奔放，没培训过的人就去现场部署没安装过的操作系统…

楼主，又见楼主 ^_^

除了业务信息系统之外，还有偏业务功能型的开源软件里，后台用到关系数据库的，国内团队开出来的，only MySQL 的明显多，而 only PostgreSQL 的几乎找不到……

用拼音首字母做表名、字段名很正常。
一来很多地方性、行业性的信息系统开发商的 crudboys 本身层次就不太行，英文水平一言难尽，尬写英文还不如用拼音。
二来业务系统的行业术语比较多，很多 crudboys 写计算机类的英文术语已经很吃力了，再去写行业的，更不现实。
三来很多行业尤其是体制内，即便是中文术语，也有太多生编硬造的长词缩写，就算是英文好的人按照原意翻译成正确、精准的英文，那也太冗长了，要从英文缩写的话那就完全无法理解，还不如拼音缩写。

少，大部分人只知道 MySQL ，大部分人是师傅教我用 MySQL 我就永远用 MySQL ，组长让我用 MySQL 我就用永远用 MySQL ，一个项目用 MySQL 我就以后继续用 MySQL ，MySQL 不开严格模式可以乱写不规范查语句节省我系统地学习 SQL 的时间我就只用 MySQL ，并且 PUA 自己 MySQL 是最满足业务需求的用 PG 是凑热闹、炫技，PUA 别人纠结个别技术细节的优劣比较没意义最重要的是实现业务逻辑…

程序员在互联网公司做的恶里占多少责任是一回事，媒体拿程序员捏软柿子是另一回事。

个人程序员的时代已经过去了。

@ospider LDAP……是想说 OLAP 吧

建议：
1. 因为项目跨度太长，必然会产生屎山和各种风格不一致，还是调整心态吧。
2. 虽然“2022 年已经快到了，使用异步代码访问数据库完全不是什么行为艺术”，但项目不是 2022 年开始的，是周期长跨度到 2022 年的，不要给自己找麻烦去迁移异步了。如果是新项目可以。
3. 既然是海蛎子查询，那还是现实一点吧。

从你自己写的就可以看出来，更多的问题是因为，1.项目演进的问题 2.SA 跟你的项目的匹配度问题

至于 SA 本身的设计路线，当然也是个问题，但并不是跟你带来痛苦的关键

“大连表复杂查询”，会不会被分词引擎分出一股海蛎子味来……

至于担心非程序员抢了程序员饭碗啥的……想多了。

现在的海量 crudboy 所作的业务功能开发，也就是名义上算是个程序员，真干起活来，大部分工作都是在理解业务。其中有不少根本就没想好好学技术，只想着重业务、转管理。这样的人，用无代码平台去做业务实现，恐怕还是比用通用的编程语言更靠谱。毕竟在无代码平台上，就可以不用管技术细节，只“重业务”了。不用担心线程同步写错了死锁，不用发明“粘包”概念，不用手拼 SQL 字符串被搞死，不用被生产环境的运维怼不规范……

这些所谓的“程序员”其实就是来抢饭碗的非程序员，无代码对他们的未来更友好。担心个毛，会进来抢饭碗的，早就来了。