@dcoder 你说的这个我也不反对，跨库场景下外键当然起不到作用，但非跨库的情况下你做的无非是自己实现了一遍数据库做的事。

对于一个团队来说，这种方式想要达到和数据库一样的效果，需要每个成员均熟悉相关知识，以及依靠大量的测试和代码 review ，即使这样也很难说完全不会出错，所以代价比直接设置外键高多了。

@Gota 非常感谢您的回复！解答了我的很多疑惑。

根据上述方案，可以将业务库的数据控制在一个较小的级别，让物理外键的存在不至于导致性能问题，同时可以利用好其完整性约束和级联操作等特性。一切的前提是需要引入一套高效可靠的日志服务，对吗？

我 28 楼的提问主要是考虑 **软删除** 这个情况下需要将数据存档。如果存在可以回放的日志，那就不需要软删除了，对数据的存档也早在记录日志时就已经完成了，这个问题也得到了解决。

@Gota 涉及到引用关系的数据在写入冷存储时似乎也只能靠开发人员约束，这就和使用逻辑外键一样了，同理还有需要在开始写入冷存储到实际删除数据前的这段时间里避免产生新的引用，也得依靠主动加锁。

要避免加锁，可以先对要删除的数据做软删除来避免后续业务引用它，再逐步删除已经存在的引用，但这依然要求开发人员在写入数据时做检查，同时因为目标数据和引用数据分别删除，需要考虑后续删除失败时手动回滚，感觉问题会变得更复杂……

@Wuuuu 筛选分为相等，排除，比较等形式，添加如 eq lt le gt ge 等标志可解，排序定义一个单独的参数即可。但我认为这只不过是一种接口设计的思路，实际上遵循的思想是 “尽可能少造轮子”，比如利用已存在的 HTTP 状态码代替自己定义错误信息，楼内也有人说了，非增删改查的复杂逻辑是很难用这种方式设计的，所以需要变通，比如当前端把筛选区做成一个很大的表单时，使用 POST 方法提交其实也很合理。

醒来看了一下各位的讨论，有以下几种情况：

@iseki 领导坚持不用这种问题确实存在，这里只考虑技术上使用物理外键是否比逻辑外键更好。我自认为已经把上下文定义得相对清晰了，即：非单表大量数据，非分布式情况，通常不超过百万但含有较复杂引用关系的业务数据。

@dcoder 确实存在认为数据库应该只做存储这一件事的看法，但这其实是放弃了 RDBMS 的部分功能，关于程序员希望少关心 SQL 这件事我也感到疑惑，因为 ORM 固然强大，但很难只靠它就写好业务逻辑，对一个后端开发人员来说了解数据库相关知识应该是必须的，而外键并不算什么特别生僻的知识吧？

典型场景下：如需要确保引用的数据存在，开发上需要先查询并加锁，再执行插入，而目前我接触过的 ORM 都不会在查询时加锁，这说明 ORM 也默认了开发者理解数据库行为并会自己去处理这件事，这显然不符合你说的 “少研究 SQL 也能写清楚逻辑”，而我疑惑的原因是手动加锁和使用外键约束相比并不高效，还需要投入额外的开发精力。

@cwek 如果 “没必要” 是说无论有和没有都不会影响功能的实现，那我也同意，但本帖想要讨论的问题是 “在（如正文描述的）一般情况下使用物理外键是否更合理”，因为我找不到使用逻辑外键可以比物理外键更高效、可靠的理由，能否从这个角度讨论问题呢？

@Gota 受教了，不过归档数据这项工作是在删除时完成更好还是定期由独立的程序完成更好呢？后者的话其实并不能避免开发时编写软删除逻辑

作为对比，Telegram 只有 90MB

正经来说，Vim 好像没有你要的这种形式，但是上移这种操作一般不都是删除整行后跳到目标位置粘贴吗……
拿你举例的「向上移动一行」来说，完全可以直接 kddp 解决，为了这种功能写函数都没必要，也不会用到 leader 吧

喜欢组合键要不要试试 Emacs （ Doge

啊这……15 款用了 6 年你说的这些我一个都没遇到过，去年年底换新到现在也没遇到，期间一直自动更新保证系统最新。
倒是新系统宣传的 FaceTime 那几个分享功能 bug 一大堆，怎么用怎么难受。
可能我装的 App 确实少，使用场景也比较固定。

好功能，不过我开始担心微软把 GitHub 做的过于复杂花哨了……

剪贴板工具的话，给不习惯 Paste 的人推荐另一个 Pasta ，注意是 a 不是 e ，App Store 可以直接下载，而且免费版似乎足够应对大部分需要了。

大概 11:30 左右恢复正常了，不知道是什么原因

加载逻辑问题，点击搜索框后等右侧加载完再开始搜索就可以

@KirbySD 回来看贴顺便补充一点，国内信用卡就我知道的是招商银行 JCB 卡是可以日区付款的，具体情况可以 V 站搜其他贴了解，如果不介意那些美区有而日区没有的服务的话日区确实是不错的。

试试日区：
1. 日区的 ACG 曲库算是相当全的，会有一些不进订阅的，可以在 iTunes 里单独买，目前没怎么遇到找不到的情况
1. 日区歌曲名称不会转罗马字，上面也有人说了
个人转美区的原因：
1. 日区绑定日文界面，需要一定语言基础，我个人虽然不是完全看不懂，但没有熟练到轻松阅读（至少专辑介绍之类的无力）
1. 美区曲库大部分也都有，缺少一些偶像企划的专辑，我觉得问题不是很大
1. 语言问题似乎和发行商提供的信息有关，现在已经不是无脑转罗马字了，一些专辑同时有日文和英文名的在美区显示为英文，新曲大多数可以正常显示假名（老歌部分还是存在罗马字问题，以及歌手名还是罗马字）
1. AppleMusic 账号绑定商店、TV 和 fitness+，日区 TV 界面我是完全看不懂，剧名都是假名……fitness+目前也没有支持日区

Options 概率性失灵，需要重启服务才能恢复（我选择注销重新登录）
Mos 很不错，如果你不需要自定义其他按键功能的话

文件不是特别多或者特别大的话，用 vim 录宏……

我这几天观察了一下，日常用基本就两个小核在跑，所以加不加感觉区别不大……如果没有特别要求 CPU 性能的需求，可以不加。
我是觉得用做坏的芯片有些别扭，虽然也没什么可在意的。