相关疑难解决方法(0)

我有下表。

create table test (
   id smallint unsigned AUTO_INCREMENT,
   age tinyint not null,
   primary key(id),
   check (age<20)
);

问题是CHECK约束不适用于年龄列。例如，当我为年龄字段插入 222 时，MySQL 接受它。

不使用 FK 约束是我公司的不为人知的规则。FK 约束仅在设计 ERD 时使用，在创建表时不使用。

据我的前辈说，在实际操作中，当我们处理紧急问题时，这些都是非常耗时的障碍。他说，当我们需要立即使用 INSERT/UPDATE/DELETE 语句时，约束会阻止这些语句的执行，并且在保持约束的同时编写语句也很耗时。我什至听说许多其他公司也在这样做。

虽然我有点理解这些挣扎，但我不确定这是否是一个好方法，因为它与我对 DB 的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理的。

实际上，您对此有何看法？这有道理吗？有更好的方法吗？其他公司在这方面的表现如何？

更新：对于韩国公司来说，这似乎是一种很常见的方法。我问了几个在别的公司工作的前辈，他们大多都说都是这样。甚至其中一个人在一家金融公司工作！有趣的...

今天早些时候，我与我的专业同行就我们公司数据库中的外键话题引发了一场相当意外的辩论。简而言之，一位比我年长的软件工程师说他不喜欢我对我们的一个存储库所做的提交，因为我在两个表之间实现了外键关系。他的论点是他不喜欢外键，因为它们限制了可以插入数据库的数据，他认为这会使数据库更难使用。（注意：他的论点一般反对外键，而不仅仅是我在我们的应用程序中提出的轶事外键约束。他认为外键约束是现代关系数据库系统中的一个设计缺陷。）

此时，我完全措手不及，我们的老板暂时选择站在高级开发人员一边，要求我从我正在处理的错误修复的实现中删除外键。我正在修复的错误实际上源于使我们的 ORM 感到困惑的关系不一致（这本身还有一些不足之处，但这是一个不同的故事），虽然我试图向我的团队解释这一点，但每个人都站在高级dev & 我被告知要回到绘图板并重新实现我的数据库修复，而不依赖于外键约束。换句话说，我被要求在没有 RDBMS（posgres，如果重要的话）的内置关系管理工具的情况下进行关系管理。

我重申这不是修复错误的正确方法，此时我的老板告诉我讨论占用了太多时间，如果我想辩论正式 FK 约束的优点，我需要以后再做……我打算这样做，但我也觉得我的任务是争论为什么水是湿的。

当我进入这场辩论时，我想用尽可能多的事实来支持外键的使用。我知道实施合理的 FK 约束：

1. 作为防止关系不一致的自动护栏（即，防止“垃圾数据”（这是我目前正在使用的系统的一个明显问题）），
2. 向正在检查数据库模式的人阐明两个相关表之间的高级关系上下文，以及
3. 可以提高数据库查询操作的性能。

......但我想知道在这个主题上是否还有其他我可能遗漏的要点，我应该用这些要点来应对这场辩论。我应该确保向我的老板和同事提出哪些其他好处？（或者真的有范式转变远离 FK 约束，当它发生时我一直把头埋在石头下？）