重置 SQL Server 中的标识列

发布于 2024-07-16 01:52:56 字数 201 浏览 4 评论 0原文

我正在制作一个存储联系人的 SQL 数据库。我希望能够删除联系人，每个联系人的正确 ID 对于我的软件连接到它至关重要。假设我已经联系了詹姆斯，他是第一个联系的。他的id是0。我添加Mary，她的id是1。如果我删除James，如何将Mary的id设置为0而不是保持1？由于她现在是第一个，所以必须重置。换句话说，当某人被删除时，如何重置数据库中的所有 ID？谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浅浅 2024-07-23 01:52:56

从很多方面来说，这都是一个糟糕的主意。我正在考虑是否应该向您展示如何做到这一点。一旦设置了行的标识，就不应该有理由更改它。

如果存在，您可能使用了错误的字段作为 PK 标识符。我在这里假设你正在谈论你的 PK 字段，它也是一个身份列。

请记住，如果您创建任何链接到您的联系人表的表并且开始更改您的 ID，您也需要更新所有这些表。哪个会变得很贵...

回复收藏 0 原文

离不开的别离 2024-07-23 01:52:56

一旦数据库中的记录数量过多，速度就会变得非常慢。标识列对您不起作用，您需要执行一些自定义 T-SQL 来不断更改所有数字 - 但在我看来，这是一个非常糟糕的主意。

如果您需要跟踪它们的添加顺序，为什么不使用日期/时间戳呢？

您需要重新考虑您的设计。

回复收藏 0 原文

心安伴我暖 2024-07-23 01:52:56

ID 不是这样工作的，也不应该是这样工作的。 ID 永远不应该改变，否则所有链接的信息都会指向错误的行。

相反，为什么不添加您控制的“External_ID”列呢？或者在查询中动态地对它们进行编号（使用计算列？）

回复收藏 0 原文

甜中书 2024-07-23 01:52:56

在自动递增主键列上执行此操作是没有意义的，即使这样做很简单，如果没有相关表中的大量更新，您也会影响数据完整性。为此，您可能需要从列中删除索引和主键约束（此时您的应用程序可能会崩溃），对所有后续记录重新编号，对所有相关表重新编号，然后重新应用主键约束和索引。

如果您确实必须拥有某种形式的线性标识符，该标识符始终从 0 开始（这可能表明软件设计存在问题），那么除了主键之外，您还可以拥有辅助 ID 列，然后将其更新以随机排列更高的值向下一级声明如下：

UPDATE table
SET secondaryID = secondaryID - 1
WHERE secondaryID > (SELECT secondaryID FROM table WHERE primaryID = [id to delete]);

DELETE FROM table
WHERE primaryID = [id to delete];

我强烈反对这种做法 - 如果您的 ID 由于删除记录而“丢失”值，则软件应该测试这些值是否存在，而不是仅仅删除。

It makes no sense to do this on an auto-incrementing primary key column, as even if it was trivial to do, without mass updates in related tables you affect your data integrity. To do so you would likely need to drop the index and primary key constraint from the column (at which point your application may flake out), renumber all later records, renumber all related tables, then re-apply the primary key constraint and index.

If you really must have some form of linear identifier which always starts at 0 (this may then indicate a problem with the software design) then you can have a secondary ID column in addition to the primary key, which you then update to shuffle higher values down a rung with a statement such as:

UPDATE table
SET secondaryID = secondaryID - 1
WHERE secondaryID > (SELECT secondaryID FROM table WHERE primaryID = [id to delete]);

DELETE FROM table
WHERE primaryID = [id to delete];

I strongly discourage such a practice - if your IDs are 'missing' values because of deleted records, the software should test for existence of these values rather than just wigging out.

回复收藏 0 原文

小…楫夜泊 2024-07-23 01:52:56

ID 是行的唯一标识符。

它可用于将一行链接到另一个表中的另一行。 ID 的缺失本身也包含信息，因为它清楚地表明它已被删除。开始回收 ID 号码完全违背了拥有唯一标识符的目的，并且实际上没有任何意义。一旦将ID分配给一行，就不能随意更改它。

想象一下，当有人去世时，他们会将他的社会保险号码 (ID) 交给其他人。这将导致将与死者社会保险号码相关的所有旧信息转移给新人，这是没有任何意义的。 ID 也会发生同样的情况，如果重新分配 ID，它将继承之前链接到它的任何旧数据。

回复收藏 0 原文

眼眸 2024-07-23 01:52:56

使用另一种方法可以比每次删除行时对标识列重新编号更好地解决这个问题。

如果不知道应用程序为何有此需求，很难确切地说您还会做什么，但您的应用程序需要此功能这一事实可能表明某个地方存在设计问题。

回复收藏 0 原文

分分钟 2024-07-23 01:52:56

您使用 id 不仅仅是一个标识符。如果是这种情况，您将无法使用自动增量字段。您需要在代码中处理这个问题。

回复收藏 0 原文

叫嚣ゝ 2024-07-23 01:52:56

1 分钟的谷歌搜索给了我一个无法显示的页面。谷歌一下，它将成为您截至 2009 年 6 月 1 日的第一个链接： tsql fix "identity column"

本质上，我建议在执行任何操作之前在所有关系字段之间添加一个外键约束到相关 ID 字段重新编号（如果存在任何关系，这也是一个可怕的想法，严格来说，因为如果你问这个问题，你会很开心）。

如果您的联系人表是您的唯一表或基于此 ID 字段具有零关系，您可以将 Identity 属性设置为 NO，将值从 1 重新编号为 COUNT(ID)，然后将 Identity 属性设置为 YES，并重新设定身份种子要完成使用：

DECLARE @MaxID INT

SELECT @MaxID = COUNT(ID) FROM TableID

DBCC CHECKIDENT('TableID', RESEED, @MaxID)

在这种情况下，您可以在每组删除之后使用上述重新设定种子脚本（但更改 COUNT (ID) 到 MAX(ID) 一旦所有内容最初并正确设置，这会在任何其他插入或外键约束更新之前增加一点速度（随着表变大）。确保使用包含删除和重新播种块的 TRANSACTIONS，并确保表只允许同步事务，这将防止在重新播种过程中存储任何数据。

复杂吧？这就是为什么最好从正确的开始。 ;)（我从经验中学到了这一点）如果您有任何其他问题，请给我发送电子邮件至 mraarone et yahoo d0t com。

回复收藏 0 原文