【问题标题】:How do I query for foreign keys that don't match their constraints?如何查询与其约束不匹配的外键?
【发布时间】:2008-11-03 18:21:21
【问题描述】:

SQL Server 2005。

我正在将外键约束添加到据称不需要它们的应用程序的数据库中。自然,数据变得不可靠,外键字段中存在孤立条目。

设置:
两个表,TableUser 和 TableOrder。 TableUser 有主键“UserID”,TableOrder 有外键“UserID”。

如何查找 TableOrder.UserID 在 TableUser.UserID 中没有匹配条目的行?

例如,TableOrder.UserID 的值为 250,但没有与 250 匹配的 TableUser.UserID 键。

【问题讨论】:

  • 找到它们后,您想用它们做什么?例如,删除它们?
  • ERRR,如果有外键怎么可能不匹配?你的 SQL 中真的有硬编码的 FK 吗?
  • 他的意思是一个表,其中的字段被应用程序视为外键,但从未由数据库本身强制执行。
  • 或者 FK 约束是事后添加的(SQL Server 默认情况下不会将它们应用于现有行),或者如果有人关闭 FK 验证以强制执行某些操作并因此搞砸了数据库(看过太多次了)。

标签: sql-server-2005 tsql foreign-keys foreign-key-relationship


【解决方案1】:

这是一种方法:

select * from TableOrder where UserID not in (select UserID from TableUser);

有许多不同的方法可以编写这种查询。

【讨论】:

    【解决方案2】:

    另一种常见的方法是左外连接:

    SELECT * FROM TableOrder o
    LEFT OUTER JOIN TableUser u ON o.UserID = u.UserID
    WHERE u.UserID is NULL
    

    此查询在没有 where 子句的情况下也很有用,可以浏览并查看相应的值(如果存在),并查看哪些不匹配。

    【讨论】:

      【解决方案3】:

      表中一开始就没有 FK 约束。它们像 FK 和 PK 一样使用,但没有编码——相信它们是不必要的开销。所以我们有所有的列,但没有编码约束。当我去把它们放进去执行它们时,我发现有很多违规行为。

      您的问题突出了问题所在。它们不是不必要的开销,它们可以防止人们对一般数据库进行破坏。

      Greg 和 Brad 的回答都帮助了我。

      【讨论】:

      • 我认为这是一个常见的误解。很多人认为这应该在业务逻辑的中间层完成。但是 FK 是任何关系数据库的基本组成部分。如果数据库做不好那还有其他问题……
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-12-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多