我没有读过如何忽略数据库中的关系，这些关系具有逻辑上相互关联的表。
我的问题是，没有在数据库中定义关系是一种特殊的获取方式吗？恕我直言，因为一些问题，如级联更新删除或其他约束RELATIONSSHIPS为开发人员。
答案 0 :(得分：1)
是否有任何理由/最佳做法不实施表格之间的关系？
主键和外键约束并不总是存在。 （需要引用）有时在早期，它们仅在代码中维护。或者关系可能已经作为表上的唯一索引而不是PK / FK关系实现。
当时的理性是，当移动数据时，关键约束变得很难管理，有一个与它们相关的开销，人们可能会像级联更新一样做愚蠢的事情，因为它们不应该级联更新因为新开发人员不了解整个系统。
主键有一些开销，它们通常代表一些任意系统分配的值，除了系统之外没有任何意义。由于存储的早期成本，数据库将使用组合密钥和节省空间所需的信息来设计。是的，节省空间非常重要。就当前的数据库设计和建模而言，这是正确的做法吗？但当时，考虑到系统的限制，它是最经济的。
现在，如果这个数据库是在过去15到20年间创建的......其中一些原因就会消失。如果超过20岁。我明白为什么它可能没有约束。
答案 1 :(得分：1)
历史上，不定义关系的一个原因是提高绩效。检查参照完整性需要时间;一些系统试图通过声称他们的代码有足够的检查来确保RDBMS内部的额外验证是多余的。
这些理由现在很少有用。我认为可能适用的唯一情况是整个架构由框架类型产品管理，100％生成表结构，100％生成查询，零手动调整需要。在这种情况下，您只需要表和索引。当然，管理这种数据库作为其私有“存储后端”的产品需要非常可靠，以避免创建孤立行，悬挂行引用以及在没有参照完整性检查的情况下蓬勃发展的其他令人不快的事情。
当我在九十年代后期开发类似的产品时，我们从未产生任何参照完整性约束。但是，我在追踪产品问题方面的经验是，我们在现场看到的很大一部分问题可以在参考完整性约束的帮助下尽早发现。这就是为什么我认为“检查冗余”的理由存在缺陷，不应被视为“最佳实践”。