显式生成唯一 ID 的标识列或 UDF？

Question

我正在争论是否最好PRIMARY KEY使用Identity Columns，我们使用显式生成唯一 id 的 UDF 。

• 我在为身份栏争论。
• 我的合作伙伴主张手动生成值，他声称
  • 通过将 UDF 放在另一个可以拥有 UDF 的桌子上
    • 锁定资源
    • 递增的ID表叫做一个字段ID_Value由1
    • 将此用作全局唯一标识符
  • 或者id+1在插入时让表做一个
  • 在没有识别约束的服务器和/或环境之间移动数据更简单；从一个有数据的数据库移动到另一个类似的数据库，比如暂存或虚拟数据。对于非生产中的测试，我们可能希望将昨天的所有记录提取到暂存以进行测试。

哪个实现更有意义？

Answer 1

你的同事是个白痴。

该解决方案不可扩展，UDF 不是并发的（与此原因相同）。以及如何处理多行插入：这将需要每行调用 UDF

并且迁移到其他 RDBMS 在现实生活中并不经常发生……您现在最好不要使用 SQL Server 并在 Oracle 上使用序列，并希望您不要迁移。

编辑：

您的更新说明移动数据是为了刷新非生产数据库。

在这种情况下，您在刷新时会忽略标识列。您不会为了使非产品加载更容易而妥协您的实现。或者使用临时表来跟踪标识值的变化。

或者使用流程：我们每天晚上从生产中更新我们的测试系统，这完全避免了这个问题。（并确保我们的产品备份也可以恢复）

Answer 2

使用标识值。生成您自己的序列表和序列值将占用大量开销，并在尝试生成数字时导致大量锁定和阻塞。

身份存在是有原因的，使用它。

当 SQL Denali 出现时，它将支持比身份更高效的序列，但您无法自己创建更高效​​的东西。

至于将记录从一个环境移动到另一个环境，要么在插入时打开 IDENTITY_INSERT，要么选中 SSIS 中的框。

Answer 3

身份栏对我来说听起来不错。我不确定我是否遵循了为什么在服务器之间移动数据很困难的逻辑。

如果您确实希望每一行都具有全局唯一标识，则可以使用 UUID，但除非您确定全局唯一性是必要的，否则我不会这样做 - 通常不是。使用 UUID 作为 id 会降低性能、增加磁盘空间需求并使调试变得更加困难——因为 UUID 的长度很难记住，也很难通过电话告诉别人，或者把它写在纸上而不会出错。