当具有标识列不是一个好主意时? [英] When having an identity column is not a good idea?

问题描述

在您只需要 1 列作为键且该列中的值可以是整数的表中，当您不应该使用标识字段时?

In tables where you need only 1 column as the key, and values in that column can be integers, when you shouldn't use an identity field?

相反，在同一个表和列中，您何时会手动生成其值并且不会为每条记录使用自动生成的值?

To the contrary, in the same table and column, when would you generate manually its values and you wouldn't use an autogenerated value for each record?

我想当表中有很多插入和删除时会出现这种情况.我对吗?还有哪些情况?

I guess that it would be the case when there are lots of inserts and deletes to the table. Am I right? What other situations could be?

推荐答案

如果您已经选择了 主键崩溃 然后我找不到不使用身份键的单一原因.通常的替代方法是 guid(它们有很多缺点，主要是大小和随机性)和应用层生成的密钥.但是在应用程序层创建代理键比看起来要困难一些，而且也不包括非应用程序相关的数据访问(即批量加载、导入、其他应用程序等).一种特殊情况是分布式应用程序，当 guid 甚至顺序 guid 可能提供站点 ID + 身份密钥的更好替代方案时..

If you already settled on the surrogate side of the Great Primary Key Debacle then I can't find a single reason not use use identity keys. The usual alternatives are guids (they have many disadvatages, primarily from size and randomness) and application layer generated keys. But creating a surrogate key in the application layer is a little bit harder than it seems and also does not cover non-application related data access (ie. batch loads, imports, other apps etc). The one special case is distributed applications when guids and even sequential guids may offer a better alternative to site id + identity keys..

这篇关于当具有标识列不是一个好主意时?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！