Sql 为什么数据库的表之间没有关系？

我从未读过关于忽略数据库中具有逻辑上相互关联的表的关系的文章

---

我的问题是，不在数据库中定义关系是获得某些东西的一种特殊方式？由于级联更新、删除或其他约束等问题，关系对开发人员有何影响。

是否有任何理由/最佳实践不实现表之间的关系？

主键和外键约束并不总是存在。（需要引用）在早期，有时它们只在代码中维护。或者，关系可能已实现为表上的唯一索引，而不是PK/FK关系

当时的理性是，当移动数据时，关键约束变得难以管理，存在相关的开销，人们有时会做一些愚蠢的事情，比如级联更新，而不应该级联更新，因为新开发人员不了解整个系统

主键有一个开销，它们通常表示一些任意的系统赋值，除了对系统没有任何意义之外。由于早期的存储成本，数据库将使用组合键和节省空间所需的信息进行设计。是的，节省空间非常重要。就目前的数据库设计和建模而言，这是正确的做法吗？不是。但在当时，考虑到系统的限制，这是最经济的

---

现在如果这个数据库是在过去15-20年中创建的。。。其中的一些原因消失了。如果超过20岁。我可以理解为什么它可能没有限制。

历史上，不定义关系的一个原因是提高性能。检查引用完整性需要时间；一些系统试图节省开支，声称他们的代码有足够的检查来保证RDBMS内部的额外验证是冗余的

如今，这种理由很少是好的。我认为唯一适用的情况是，整个模式由框架类型的产品管理，100%生成表结构，100%生成查询，并且不需要手动调整。在这种情况下，您所需要的只是表和索引。当然，作为其私有“存储后端”管理此类数据库的产品需要非常可靠，以避免创建孤立行、悬空行引用以及在没有引用完整性检查的情况下出现的其他令人不快的事情

---

当我在90年代后期开发这样的产品时，我们从未生成任何引用完整性约束。然而，我在跟踪产品问题方面的经验是，我们在该领域看到的问题中，有很大一部分可以在引用完整性约束的帮助下尽早发现。这就是为什么我认为“检查冗余”的原理是有缺陷的，不应该被视为“最佳实践”。

没有关系的数据库通常是由一个无知/粗心的人创建的。我见过草率和/或懒惰的开发人员没有定义FK。它们也有可能是在升级/转换过程中丢失的，或者只是出于意外。您究竟检查了哪些关系以确定它们是否存在？仅仅因为没有数据库图并不意味着没有关系。可能是一个老的主框架转换到“新技术”而忽略了新的更好的规则。如果是数据仓库，这就可以了。在加载过程中会检查逻辑PK/FK约束，因为您不想插入/选择2000万行，其中一行会导致回滚。如果它已经被检查过，就不需要消耗大量的资源并再次检查它。