我只知道Oracle数据库，不知道其他数据库，而且我知道外键对于保持数据完整性是必不可少的。在插入数据之前，需要建立一个数据结构，并且建立正确的数据结构。当这一步完成时——所有的主键和外键都创建好了——工作就完成了!

意思是:孤立的行?不。这辈子都没见过。除非一个糟糕的程序员忘记了外键，或者他在另一个层次上实现了外键。在Oracle的环境中，这两者都是巨大的错误，会导致数据复制、孤儿数据，从而导致数据损坏。我无法想象一个没有强制FK的数据库。在我看来是一片混乱。这有点像Unix权限系统:假设每个人都是root用户。想想混乱吧。

外键是必不可少的，就像主键一样。这就像是说:如果我们移除主键会怎样?那么，整个混乱将会发生。这是什么。不能将主键或外键的职责移到编程级别，但必须移到数据级别。

缺点呢?是的，当然!因为在插入时，会有更多的检查。但是，如果数据完整性比性能更重要，那么这是显而易见的。Oracle上的性能问题更多地与索引有关，索引包含PK和FK。

没有充分的理由不使用它们……除非孤行对你来说不是什么大问题。

对我来说，如果您想要遵循ACID标准，那么拥有外键以确保引用完整性是至关重要的。

外键对于任何关系数据库模型都是必不可少的。

我同意德米特里的回答，说得很好。

For those who are worried about the performance overhead FK's often bring, there's a way (in Oracle) you can get the query optimiser advantage of the FK constraint without the cost overhead of constraint validation during insert, delete or update. That is to create the FK constraint with the attributes RELY DISABLE NOVALIDATE. This means the query optimiser ASSUMES that the constraint has been enforced when building queries, without the database actually enforcing the constraint. You have to be very careful here to take the responsibility when you populate a table with an FK constraint like this to make absolutely sure you don't have data in your FK column(s) that violate the constraint, as if you do so you could get unreliable results from queries that involve the table this FK constraint is on.

我通常在数据集市模式中的某些表上使用这种策略，但在集成登台模式中不使用。我要确保复制数据的表已经强制执行了相同的约束，或者ETL例程强制执行了该约束。

我相信有很多应用程序可以使用它，但这不是最好的主意。您不能总是指望您的应用程序能够正确地管理数据库，坦白地说，管理数据库不应该是您的应用程序非常关心的问题。

如果您正在使用关系数据库，那么似乎应该在其中定义一些关系。不幸的是，这种态度(您不需要外键)似乎被许多应用程序开发人员所接受，他们宁愿不为数据完整性等愚蠢的事情所困扰(但需要这样做，因为他们的公司没有专门的数据库开发人员)。通常在这些类型的数据库中，你很幸运只有主键;)