如何删除sql server中的外键约束？答案

【问题标题】：How to remove foreign key constraint in sql server?如何删除sql server中的外键约束？
【发布时间】：2021-07-15 02:57:13
【问题描述】：

我想从另一个表中删除外键，以便插入我选择的值。

我是数据库新手，所以请告诉我正确的 sql 查询以删除或删除外键值。

【问题讨论】：

How do I drop a foreign key in SQL Server?的可能重复

标签： sql-server database foreign-keys

【解决方案1】：

尝试关注

ALTER TABLE <TABLE_NAME> DROP CONSTRAINT <FOREIGN_KEY_NAME>

参考：http://www.w3schools.com/sql/sql_foreignkey.asp

【讨论】：

我没有添加任何约束名称。如何删除该约束？
即使您不指定约束名称，SQL Server 也会分配一个唯一的约束名称。您可以使用 SQL Management Studio 找到名称。
@Nytux OP 明确指出平台是 MS SQL Server，而不是 PostgreSQL（标签和问题标题）。

【解决方案2】：

在参考referential integrity 时这样做是错误的，因为一旦它坏了就不容易再次打开它而不必检查记录并删除那些打破约束的记录。

反正语法如下：

ALTER TABLE Tablename DROP CONSTRAINT ContName;

参见 MSDN：

【讨论】：

不，SQL Server 中删除外键和主键的语法是一样的：alter table drop constraint
@demoncodemonkey ContName 或应该是现有表中的列名还是我们在当前表中用作外键的原始表中的列名？
@iatharva 它是约束的名称 - 例如 PK_Users_Id 或 FK_Users_Id 等。您可以使用 SELECT name FROM sys.foreign_keys 查看数据库中的所有外键。祝你好运！

【解决方案3】：

ALTER TABLE [TableName] DROP CONSTRAINT [CONSTRAINT_NAME]

但是，小心，一旦你这样做了，你可能永远不会有机会回来，你应该阅读一些基本的数据库书籍，看看我们为什么需要外键

【讨论】：

只要引用完整性仍然存在，如果他想重新添加约束，他可以再次添加。如果不是，那无论如何都必须修复。
@Tobberoth，是的，我的意思是，谢谢你说清楚。在现实世界中，大多数时候其他开发人员会弄乱表中的数据，并且由于那里的数据，您无法将约束添加回来。

【解决方案4】：

要从数据库中删除所有约束：

SELECT 'ALTER TABLE ' + Table_Name  +' DROP CONSTRAINT ' + Constraint_Name
FROM Information_Schema.CONSTRAINT_TABLE_USAGE

【讨论】：

【解决方案5】：

删除一个表的所有外键：

USE [Database_Name]
DECLARE @FOREIGN_KEY_NAME VARCHAR(100)

DECLARE FOREIGN_KEY_CURSOR CURSOR FOR
SELECT name FOREIGN_KEY_NAME FROM sys.foreign_keys WHERE parent_object_id = (SELECT object_id FROM sys.objects WHERE name = 'Table_Name' AND TYPE = 'U')

OPEN FOREIGN_KEY_CURSOR
----------------------------------------------------------
FETCH NEXT FROM FOREIGN_KEY_CURSOR INTO @FOREIGN_KEY_NAME
WHILE @@FETCH_STATUS = 0
    BEGIN
       DECLARE @DROP_COMMAND NVARCHAR(150) = 'ALTER TABLE Table_Name DROP CONSTRAINT' + ' ' + @FOREIGN_KEY_NAME

       EXECUTE Sp_executesql @DROP_COMMAND

       FETCH NEXT FROM FOREIGN_KEY_CURSOR INTO @FOREIGN_KEY_NAME

    END
-----------------------------------------------------------------------------------------------------------------
CLOSE FOREIGN_KEY_CURSOR
DEALLOCATE FOREIGN_KEY_CURSOR

【讨论】：

你错了 parent_object_id ...它应该在 referenced_object_id 的状态下使用

【解决方案6】：

在完全删除约束之前，您应该考虑（暂时）禁用它。

如果您查看表创建 TSQL，您会看到如下内容：

ALTER TABLE [dbo].[dbAccounting] CHECK CONSTRAINT [FK_some_FK_constraint]

你可以跑

ALTER TABLE [dbo].[dbAccounting] NOCHECK CONSTRAINT [FK_some_FK_constraint]

...然后插入/更新一堆违反约束的值，然后通过运行原始CHECK 语句将其重新打开。

（我不得不这样做以清理我过去继承的设计不佳的系统。）

【讨论】：

【解决方案7】：

根据您使用的 DB，有一种语法或其他语法。

如果您使用的是 Oracle，则必须输入其他用户告诉您的内容：

ALTER TABLE table_name DROP CONSTRAINT fk_name;

但是如果你使用 MySQL 那么这会给你一个语法错误，你可以输入：

ALTER TABLE table_name DROP INDEX fk_name;

【讨论】：

【解决方案8】：

首先使用

show create table table_name;

查看表格的描述性结构。

在那里，您可能会看到与您在该表中使用的外键相关的约束。首先用

删除相应的约束

alter table table_name drop constraint constraint_name;

然后删除您想要的相应外键或列...祝你好运！！

【讨论】：

【解决方案9】：

ALTER TABLE table
DROP FOREIGN KEY fk_key

编辑：没注意到你在使用 sql-server，我的错

ALTER TABLE table
DROP CONSTRAINT fk_key

【讨论】：

【解决方案10】：

使用这些查询查找所有 FK：

Declare @SchemaName VarChar(200) = 'Schema Name'
Declare @TableName VarChar(200) = 'Table name'

-- Find FK in This table.
SELECT 
    'IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N''' + 
      '[' + OBJECT_SCHEMA_NAME(FK.parent_object_id) + '].[' + FK.name + ']' 
      + ''') AND parent_object_id = OBJECT_ID(N''' + 
      '[' + OBJECT_SCHEMA_NAME(FK.parent_object_id) + '].[' 
      + OBJECT_NAME(FK.parent_object_id) + ']' + ''')) ' +

    'ALTER TABLE ' +  OBJECT_SCHEMA_NAME(FK.parent_object_id) +
    '.[' + OBJECT_NAME(FK.parent_object_id) + 
    '] DROP CONSTRAINT ' + FK.name
    , S.name , O.name, OBJECT_NAME(FK.parent_object_id)
FROM sys.foreign_keys AS FK
INNER JOIN Sys.objects As O 
  ON (O.object_id = FK.parent_object_id )
INNER JOIN SYS.schemas AS S 
  ON (O.schema_id = S.schema_id)  
WHERE 
      O.name = @TableName
      And S.name = @SchemaName


-- Find the FKs in the tables in which this table is used
  SELECT 
    ' IF  EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N''' + 
      '[' + OBJECT_SCHEMA_NAME(FK.parent_object_id) + '].[' + FK.name + ']' 
      + ''') AND parent_object_id = OBJECT_ID(N''' + 
      '[' + OBJECT_SCHEMA_NAME(FK.parent_object_id) + '].[' 
      + OBJECT_NAME(FK.parent_object_id) + ']' + ''')) ' +

    ' ALTER TABLE ' +  OBJECT_SCHEMA_NAME(FK.parent_object_id) +
    '.[' + OBJECT_NAME(FK.parent_object_id) + 
    '] DROP CONSTRAINT ' + FK.name
    , S.name , O.name, OBJECT_NAME(FK.parent_object_id)
FROM sys.foreign_keys AS FK
INNER JOIN Sys.objects As O 
  ON (O.object_id = FK.referenced_object_id )
INNER JOIN SYS.schemas AS S 
  ON (O.schema_id = S.schema_id)  
WHERE 
      O.name = @TableName
      And S.name = @SchemaName

【讨论】：

【解决方案11】：

或者，您也可以从 SQL Server Management Studio 本身中删除外键约束。 如果命令不起作用，您可以尝试一下。

扩展您的数据库视图。
右键单击具有外键约束的表。选择设计。将打开一个包含有关表格列信息的选项卡。
右键单击具有外键引用的列。或者您可以右键单击任何列。选择关系。
将在弹出窗口中显示关系列表（如果有的话）。
您可以从那里删除外键约束。

希望对你有帮助

【讨论】：

【解决方案12】：

如果您发现自己处于自动生成表的 FK 名称并且您无法查看它的确切内容（例如，在没有数据库权限的情况下）的情况下，您可以试试这样的：

DECLARE @table NVARCHAR(512), @sql NVARCHAR(MAX);
SELECT @table = N'dbo.Table';
SELECT @sql = 'ALTER TABLE ' + @table
    + ' DROP CONSTRAINT ' + NAME + ';'
    FROM sys.foreign_keys
    WHERE [type] = 'F'
    AND [parent_object_id] = OBJECT_ID(@table);
EXEC sp_executeSQL @sql;

建立一个存储过程，它在不指定实际 FK 名称的情况下删除指定表的约束。它会删除对象[type] 等于F（外键约束）的约束。

注意：如果表中有多个 FK，它将全部删除。因此，如果您的目标表只有一个 FK，则此解决方案效果最佳。

【讨论】：

【解决方案13】：

如果你不知道外键约束名，那么试试这个来找到它。

sp_help 'TableName'

另外用于不同的架构

sp_help 'schemaName.TableName'

然后

ALTER TABLE <TABLE_NAME> DROP CONSTRAINT <FOREIGN_KEY_NAME>

【讨论】：

【解决方案14】：

为了更安全，只需命名所有约束并在评论部分记下它们。

ALTER TABLE[table_name]
DROP CONSTRAINT Constraint_name

【讨论】：

如果您忘记命名约束，phpMyAdmin 会为您使用的任何约束提供唯一名称。要通过 phpMyAdmin 检查这个给定的唯一名称：单击工作台左侧的 INFORMATION_SCHEMA 点击。在此之后，向下滚动并找到 TABLE_CONSTRAINTS 并单击它。在那里，您将看到在各个列上设置的所有约束及其名称和其他详细信息。

【解决方案15】：

alter table <referenced_table_name> drop  primary key;

外键约束将被移除。

【讨论】：

删除引用表的主键可能是尝试解决问题的最糟糕的方法。哦，等等 - 删除引用的表本身可能会更糟。
这回避了所提问题的本质