在数据库中定义外键还是在应用程序的代码部分中定义外键更好？
不使用 FK 约束是我公司的不为人知的规则。FK 约束仅在设计 ERD 时使用，在创建表时不使用。
据我的前辈说，在实际操作中，当我们处理紧急问题时，这些都是非常耗时的障碍。他说，当我们需要立即使用 INSERT/UPDATE/DELETE 语句时，约束会阻止这些语句的执行，并且在保持约束的同时编写语句也很耗时。我什至听说许多其他公司也在这样做。
虽然我有点理解这些挣扎，但我不确定这是否是一个好方法，因为它与我对 DB 的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理的。
实际上，您对此有何看法？这有道理吗？有更好的方法吗？其他公司在这方面的表现如何？
更新：对于韩国公司来说，这似乎是一种很常见的方法。我问了几个在别的公司工作的前辈，他们大多都说都是这样。甚至其中一个人在一家金融公司工作！有趣的...
我对数据库这个主题很陌生，所以这可能听起来很无知，但我很好奇为什么应该在表中明确显示一个键。这主要是为了告诉用户给定的列值（希望）保证在每一行中都是唯一的？即使没有提到它的独特性，它也应该仍然存在。
我正在与我工作的公司的开发人员进行永久讨论，因为他们说最好摆脱关系数据库中的关系强制（通过 FOREIGN KEY 约束定义）以加快大型查询并获得更好的结果表现。
考虑的平台是MySQL 5.x，没有设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对我来说是不合理的。也许他们是对的，我是错的，但我没有足够的论据来讨论这种情况。
三年来，这一直是首选方法。我是这家公司的新人（只有一个月），但是，随着产品“有效”，我对增强数据库犹豫不决；尽管如此，我注意到的第一件事是加载一个页面需要 1 分钟（是的，60 秒！）。
当前状况背后的说法之一是“非规范化”数据库比规范化数据库更快，但我不相信这是真的。
大多数相关查询都包括 JOIN 操作，这使得它们在处理大量数据（数据库包含数百万行）时运行非常非常缓慢。
通常，“CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据，让我们说TableA：
TableA和TableB，你能帮我详细阐述一个好的、准确的和可靠的答案来丰富辩论吗？
注意：以前可能有人问过（并回答过）类似的问题，但我无法通过 Google 找到任何内容。
mysql normalization database-design relational-theory denormalization