0

披露：我自己是一个“自然钥匙”的拥护者，反对 IDENTITY PK 方法。但我确实对生活方式的选择有一种“活下去，让生活”的方法，所以请不要在这里争论宗教：）

我继承了一个表，其中唯一的键是 IDENTITY PK 列；我们称之为 ID。有许多引用 ID 的表。创建新实体的预期过程似乎是：

  1. 插入表格。
  2. 使用 scope_identity 获取自动生成的 ID。
  3. 使用自动生成的 ID 插入相关表。

实际上，有一个辅助存储过程来创建实体并返回 ID。但是，我有几个问题：

我需要比辅助存储过程更进一步，并在相关表中创建行，这些表本身具有 IDENTITY PK，因此对于每个实体，我需要沿途获取几个自动生成的值。我需要制造数百个实体，并且帮助程序被编码为一次处理一个实体。

使用“IDENTITY PK”设计批量制造实体的最佳方法是什么？

当使用我自己的“自然键”设计时，我可以提前生成键值，因此这只是加载一些临时表并按照外键预期的顺序插入到表中的情况。因此，我很想找到一个我知道现在没有使用的高值 INTEGER 值序列（以匹配 IDENTIY 列的类型），并希望到时候它们不会被使用插入。这是一个好主意吗？

4

1 回答 1

0

您是在专门谈论 MS SQL Server 吗？

不幸的是，默认情况下 IDENTITY 列不允许显式插入。在其他 DBMS 中，自动递增不会阻止您将显式值插入该列，这将使提前选择键变得容易。不幸的是，在 SQL Server 上，您需要担心SET IDENTITY_INSERT带来的不便。

有一个辅助存储过程来创建实体并返回 ID。

对我来说，为此使用 sproc 似乎有点过头了，因为它通常就像选择SCOPE_IDENTITY()一样简单。通常，您可以通过编写每个插入来避免显式选择，这样它就可以直接使用最后一个插入的 SCOPE_IDENTITY() 。

找到一个我知道现在没有使用的高价值 INTEGER 值序列，并希望它们不会被使用 [...] 这是个好主意吗？

它们不一定必须是非常高的值；事实上，如果你经常这样做，你会在 IDENTITY 值中产生许多巨大的差距，这通常是最好避免的。您甚至可以使用这些MAX(column)+1值，只要您发现其他人在两次之间使用这些值的错误，或者更好的是，执行 select-max 然后插入事务。

于 2009-11-09T10:36:04.493 回答