将 IDENTITY PK 列添加到现有 SQL SERVER 表是否安全？

Question

在将我的一个 SQL SERVER 数据库中的所有表重建到一个新数据库后，我未能将许多表的“ID”列设置为 IDENTITY 和 PRIMARY KEY。他们中的大多数都有数据。

我发现了这个 T-SQL，并且已经成功地为几个表实现了它。新的/替换的 ID 列包含与前一列相同的值（仅仅是因为它们来自我导入的表中的自动递增列），并且我现有的存储过程仍然有效。

Alter Table ExistingTable
Add NewID Int Identity(1, 1)
Go

Alter Table ExistingTable Drop Column ID
Go

Exec sp_rename 'ExistingTable.NewID', 'ID', 'Column'

--Then open the table in Design View, and set the new/replaced column as the PRIMARY KEY
--I understand that I could set the PK when I create the new IDENTITY column

新的/替换的 ID 列现在是表中的最后一列，到目前为止，我还没有遇到调用存储过程的 ASP.Net/C# 数据访问对象的问题。

如前所述，这些表中的每一个都没有设置 PRIMARY KEY（也没有 FOREIGN KEY）。考虑到这一点，我是否应该采取任何其他步骤来确保数据库的完整性？

我遇到了this SO 帖子，它建议我应该运行“ALTER TABLE REBUILD”语句，但由于没有设置 PK，我真的需要这样做吗？

最终，我只是想确保我不会制造直到游戏后期才会出现的问题，并确保我正在实施的方法合理、合乎逻辑并确保数据完整性。

我想用正确的 PK/IDENTITY 列来 DROP/RECREATE 表可能是一个更好的选择，我可以编写一些 T-SQL 将现有数据转储到 TEMP 表中，然后删除/重新创建，然后重新- 使用 TEMP 表中的数据填充新表。我特别避免了这个选项，因为它看起来更具侵略性，而且我不完全理解它对依赖于这些表的存储过程/函数等意味着什么。

这是我执行过此操作的其中一张表的示例。可以看到NewID的值和原来的ID是一样的。enter image description here

Answer 1

试一试；它是从我们几年前在类似情况下使用的脚本中翻出来的，不记得它是针对哪个版本的 SQLS 使用的。如果它适用于您的场景，您可以将其调整到您的表中。。

SELECT MAX(Id)+1 FROM causeCodes -- run and use value below

CREATE TABLE [dbo].[CauseCodesW]( [ID] [int] NOT NULL IDENTITY(put_maxplusone_here,1), [Code] [varchar](50) NOT NULL, [Description] [varchar](500) NULL, [IsActive] [bit] NOT NULL )


ALTER TABLE CauseCodes SWITCH TO CauseCodesW;

DROP TABLE CauseCodes;

EXEC sp_rename 'CauseCodesW','CauseCodes';

ALTER TABLE CauseCodes ADD CONSTRAINT PK_CauseCodes_Id PRIMARY KEY CLUSTERED (Id);

SELECT * FROM CauseCodes;

您现在可以找到任何对该表具有 FK 的表并重新创建这些关系。