passerbytiny

现在那贴子回复“又来割韭菜”的又增加了两个人。所以楼主，再补充两张图吧。

如果只看那个贴子，那么那个人是“明白人提醒别人别受骗”，所以楼主压根跳过原帖，直接人肉别人，好手段。

虽然我也 git 是命令行为主 UI 为辅，但是对楼主的回复仍然是一个字：哦。

“我擦，我在阿里云的服务器被黑了，有个脚本访问 aliyun.one”——标题更正。

回档难不难，看架构的。要是事件存储式的架构，那回档相当容易。要是常规数据处理方式+操作日志的架构，那是回不了档的，只能根据日志做反向处理使其看起来像回档。要是只有 CRUD，那连反向处理都做不了，只能依靠神操作——人工或脚本修改数据库——回档了。

据说，游戏开发，尤其是网游开发，是没有通用架构的。但看楼主描述的操作方式，大概这游戏的架构是上述最后一种。

@Just1n 接口让前端定义还是后端定义、多服务的数据整合让前端处理还是后端门面处理、用 Java8 还是用 Java11，这些是没有定论要看情况选择的。但是，“用业务上的约束还是数据库外键”，跟“面向对象还是面向过程”、“基于领域模型还是基于 CRUD”、“代码编程还是数据库编程”、“用模板还是用 JSP”这些问题一样，是有定论答案的，即：只要有能力有条件用前者，就不能用后者。

虽然你不啦不啦了一大堆，但是你是站在 DBA （或者不混程序员社区的老程序员）的角度上看问题的，并不是在程序员的角度上看问题。推测原因：
一、楼主年少只在 JD 实习过，拿 JD 的经验来说事，你就认为只有 JD 是这么干的；然而事实是，不管是培训班，还是复制粘贴博客，还是大厂里的正式规范，数据库外键都是严禁的（例：〔阿里编码规约〕 [强制] 不得使用外键与级联，一切外键概念必须在应用层解决）。
二、你在 SO 的搜索关键字是“DB foreign Key pros and cons”，然而要是程序员搜索，关键字是“program or db foreign key to make constraint”

@b821025551b #31 我没做过银行项目，但是能猜的出银行即使用了数据库外键，仍然会有其它手段去做约束，因为即使你用上了包括外键在内的所有数据库上的约束手段，那还是不如一份严格的测试报告保险。数据库外键对于银行项目来说，只能算作锦上添花的保险设施，并不是必要条件。

A：所以你也就过过“误人子弟的书”的嘴瘾，别人能出书。（你比那个人差得远了）
B：我比别人差得远，我就不能说别人误人子弟了？

提问：B 的脑回路为何如此奇特。

@l8g #63 哦

@pence2019 自己列目标然后让副手执行；高危目标只列目标不列计划；为了注释而注释：你这领导也许是一个合格的 ZZ 领导，但绝对是一个垃圾的技术领导。再加上，都全员反弹了副手还要到网上找出路（而不是高层），能跑路就抓紧跑路吧。