在实际操作中不使用外键约束。可以吗？

Question

不使用FK约束是我公司的规则。FK约束仅在设计ERD时使用，而在创建表时不使用。

据我的大四学生说，在实际的实践中，这些都是我们处理紧急问题时非常费时的障碍。他说，当我们需要立即使用INSERT/UPDATE/DELETE语句时，约束会阻止要执行的语句，并在保留约束的同时编写语句也很费时。我甚至听说很多其他公司也在这样做。

虽然我有点理解这些挣扎，但我不确定这是否是一种好方法，因为这与我对DB的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理这一问题的。

实际上，你对此有何看法？这是否合理呢？有没有更好的方法？其他公司如何应对这一问题？

更新:对于韩国公司来说，这似乎是一种相当普遍的做法。我问了几个在其他公司工作的高年级学生，他们中的大多数都说他们都是这样做的。甚至其中一人在一家金融公司工作！有趣的是。

Answer 1

你的高年级犯了令人讨厌的错误。FK约束是确保数据完整性的一行代码。需要更多的时间，

• 从字面上讲，在声明性语言中有一行代码，有时在CREATE表中可以内联添加外键。
• 或者，假设完整性，并处理失败的假设的缺点。

没有理由不使用外键约束，也没有理由不使用关系数据库。您有两个作为SQL的作业：

• 使用DDL创建架构。
• 使用DML访问架构。

如果没有使用模式确保数据的完整性，则只需跳过工作的一部分。事务的本质就是确保原子化、全无或无。您想在不使用外键约束的情况下定义"all“？那是个皮塔。

CREATE TABLE foo ( int a PRIMARY KEY );
CREATE TABLE bar ( int b REFERENCES foo );
CREATE TABLE baz ( int b );

现在为bar和baz执行原子事务

1. 将值(1)插入到foo.a中。如果存在值，则失败。
2. 将相同的值插入到其他表(bar.b或baz.b)中，如果foo.a中不存在该值，则失败。

哪一个是节省时间的？

Answer 2

在DBMS中声明外键约束几乎总是比使用没有约束的外键更好。外键约束维护引用完整性，从而防止一种形式的数据损坏。

在应用程序级别执行引用完整性的替代方法几乎总是在计算机资源和程序员的工作上花费与DBMS约束一样多的费用。

不保持引用完整性的替代方法通常会导致数据损坏和结果不可靠。

你的网站的政策从一开始就被错误的可能性很大。这方面也有例外，但数量很少。

Answer 3

这确实需要针对您自己的情况进行测试，但是要提供外键的数据完整性，同时快速删除或更新数据，您可以查看级联。

CREATE TABLE ChildTable (
    id INT NOT NULL IDENTITY(1,1), 
    parent_id INT,
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);