肉存

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

这就是阿里

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

楼主，又见楼主 ^_^

除了业务信息系统之外，还有偏业务功能型的开源软件里，后台用到关系数据库的，国内团队开出来的，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 字符串被搞死，不用被生产环境的运维怼不规范……

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

考虑到当代主流 crudboys 的水平和素养，以及主流架构师们热爱的臃肿肥大的技术栈，其实你对无代码工具的质量、性能、可维护性的担忧并不是什么大问题，毕竟人写的代码也好不到哪里去，甚至很有可能更糟糕。

@gridsah 好吧，我只是觉得，如果不是因为客户的原因，真的没必要坚持 RHEL （以及以尽量兼容 RHEL 为原则在没有 RHEL 的环境选择第二发行版），哪怕用年纪比较大不想折腾为理由。蓝帽厂能这样玩一次 CentOS 老用户群，以后就能玩出更多的幺蛾子。与其用这些 derivatives 妥协，不如及早抽身。

更看不到你必须在一个公网的 VPS 里用 RHEL 的理由。如果 RHEL 是你如痴如醉的坚定信念，那么砸钱买云服务大厂的贵 VM 。但是从你讲的来看，真没有必要坚持。

@gridsah 你洋洋洒洒一大串，看不到必须用 RHEL 的理由。