专门考虑网络应用，
（1）为什么RDBMS中的关系（即：外键）甚至有用？
我编写的Web应用程序具有内置逻辑，可根据必填字段验证用户输入。我认为没有真正使用外键，因此没有真正用于关系数据库。
此外，如果我将所有必需的字段验证逻辑放在RDBMS中（即：MySQL），它只会返回一个模糊的错误。至少使用基于PHP的验证，我知道哪个字段丢失了，我可以通知用户（虽然使用基于Javascript的验证，这几乎不会发生。）
（2）过去有没有一点RDBMS由于某种原因有用，或者他们现在有用的原因我不知道？
我真的需要对这个主题有所了解。我根本无法想出一个好的答案。
答案 0 :(得分：7)
我将从另一个角度来看待这个问题。
我在一个我们有一个数据库的地方工作，该数据库在其初始记录数据库中没有任何外键约束，默认值或其他数据检查。首席工程师的借口与上述内容类似。 “该应用程序将确保参照完整性。”
问题是，我们没有在数据库顶部的标准数据层（如对象关系映射）。我们有多个程序源可以输入相同的表。这很有趣，因为过了一段时间，你可以知道代码的哪些部分创建了表中的哪些行。有时链接排成一列，有时他们没有。有时链接是NULL（当它们不应该是），有时它们是0.我们甚至有一些很有趣的循环记录。
我的观点是，您永远不知道何时需要编写快速脚本来批量导入记录，或编写引用相同表的新子系统。 作为程序员，我们应该尽可能地采取防御措施。我们不能假设那些跟在我们后面的人会知道我们的架构应该如何使用（如果有的话）。
答案 1 :(得分：5)
我不是一个SQL爱好者，但即使我必须说关系结构也有其优势。
它不仅允许验证。通过向数据库提供描述存储的实际件数信息之间关系的元数据，可以进行大量优化。
这使得快速检索大型复杂数据集成为可能。它还减少了进行修改所需的查询次数并保持数据的一致性，因为大多数“簿记”都是在连接的DB端自动执行的。
答案 2 :(得分：1)
大多数关系数据库中外键的一个非常有用的功能是级联。
假设您有一个族表和一个人员表。每个家庭可以有多个人，但一个人只能属于一个家庭（一对多的关系）。如果您有外键并删除了系列行，则数据库可以自动更新所有相关人员，方法是删除它们或将其外键设置为null。
如果您没有此约束，则必须在自己的代码中自行处理这种情况。
答案 3 :(得分：1)
RDBMS仍然非常有用。不知道为什么你不这么认为。外键约束可以用来维护引用完整性（换句话说，提供一种简单的方式来表达1：1,1：很多很多：很多关系.RDBMS也很有用，因为有一个丰富的理论伴随着实际的发展，不像以前的DBMS。特别是关系演算/代数很好，因为它们允许良好的查询优化，规范化等。
不确定这是否真的能回答你的问题。维基百科可能列出了RDBMS的一些优点。
答案 4 :(得分：1)
（1）为什么RDBMS中的关系（即：外键）甚至有用？ 首先，我认为你在谈论外键CONSTRAINTS。外键只是一个逻辑设计功能，表示该实体与该实体匹配。
外键约束有用的原因是：
他们帮助您坚持DRY（不要重复自己）原则。当然你的应用验证了这种关系，但它是否在几个地方做到了？是否有多个应用访问同一个数据库？你必须在每个应用程序中重复逻辑吗？嘿，你可以把这个逻辑拉出来并使用一个通用的DLL来访问强制执行该逻辑的那些数据。但是，如果它被内置到RDMBS中，那么我不必编写自定义代码来执行如此常规的操作？巴姆。外键约束。
如果您的应用强制执行外键验证，那么如何强制直接在数据库中工作的用户遵守您的规则？我知道我知道。您不应该让用户直接进入后端，但是当他们有一个企业项目并且您是瓶颈时，您只是尝试告诉数据分析师。
关于模糊的错误。当数据未通过外键约束检查时，RDBMS X是否存在模糊错误，您的论证是否会更好？你概括它的方式，你也可以说我们应该使用纸质分类帐而不是计算机，因为约束有一个模糊的错误。
（2）过去有没有一点RDBMS由于某种原因是有用的，或者是否因为我不知道它们是有用的？ 是的，那将是现在，昨天，可能很长一段时间。
我可以永远继续说明理由，但这里是最重要的...... 它提供了一种易于扩展的通用结构化文件格式，可供其他应用程序使用。你可能太年轻了，不记得每个dang系统都拥有它自己的专有结构化文件格式，但它很糟糕。此外，它还强迫您在索引，查询语言，锁定等方面不断重新发明轮子。
答案 5 :(得分：1)
“我认为没有真正使用外键，因此没有真正的用途 关系数据库“
从这句话来看，你似乎低估了关系数据库的用途。外键约束不是关系数据库的定义特征，当然也不是使用此类数据库的唯一原因。关系数据库模型是一种强大而有效的表示数据的方法，即使您决定不想实现外键约束，它仍然是如此。因此，我将假设您真正要问的问题是：为什么外键在关系数据库中有用？
外键约束只是一种数据完整性约束。您当然可以在数据库外部实现完整性规则，但DBMS经过精心设计和优化，可以为您完成工作，并且通常是最有效的地方，因为它最接近数据结构。如果你在数据库之外完成它，那么你至少需要额外的往返来检索必要的数据。您还必须在应用程序代码中复制DBMS的锁定/并发模型。
数据库优化器可以利用数据库中的约束来提高查询性能。如果规则仅存在于您的应用程序代码中，则无法执行此操作。
如果有许多应用程序共享同一个数据库，那么在每个应用程序中实现数据完整性规则是不切实际且维护成本高昂的。集中约束逻辑更有意义。
各种CASE工具和DBA工具将利用数据库约束，可以对它们进行反向工程并使用它们来协助开发和维护任务。
在实践中，数据库约束与仅在进入时验证数据的某些过程代码的含义和功能是非常不同的。如果X在数据库约束中实现，那么我知道它对数据库中的每个数据都有效。如果在输入数据时在应用程序中实现了X，那么我只知道它适用于未来的数据 - 我无法确定它是否适用于数据库中已有的所有内容（可能X仅在今天实施且不适用于数据昨天进入了。）
答案 6 :(得分：0)
因为它们保持了数据库的完整性。如果您在应用程序中拥有所有业务逻辑，那么理论上它们不是必需的，但仍可用作防止错误数据的安全措施。