在数据模型类中使用 uint 而不是 int 作为主键是个好主意吗？答案

【问题标题】：Is it good idea to use uint instead of int as the primary key in data model class?在数据模型类中使用 uint 而不是 int 作为主键是个好主意吗？
【发布时间】：2019-11-16 12:08:16
【问题描述】：

我们知道主键通常是正整数。

使用uint 而不是int 作为数据模型类中的主键是个好主意吗？

示例：

public class Customer
{
   public uint CustomerId {get;set;}
   //others are omitted for the sake of simplicity.
}

【问题讨论】：

你太乐观了，认为 9,223,372,036,854,775,807 对你来说还不够；-)
@zerkms：别想了。这超出了我的想象。
@回收站：那就没有区别了。
@zerkms：我改成uint 让它更务实。
@回收站：如果 2,147,483,647 太少，那么值得更改。

标签： c# entity-framework

【解决方案1】：

对应的 SQL 数据类型是带符号的数字，所以我会坚持使用int 以避免任何意外。

【讨论】：

可以把对应的SQL数据类型改成uint吗？
@Recycle Bin：我不知道，我不确定你为什么要这样做。如果你真的需要超过 20 亿个数字，你可以随时切换到 bigint，或者考虑使用 UniqueIdentifier 之类的东西。

【解决方案2】：

万一其他人偶然发现了这个问题 - 不要使用 uint 作为您的密钥。我刚刚使用 Entity Framework 6.1.12 进行了尝试，但代码一直因神秘的“实体没有密钥”异常而失败。

只有在我将 uint 属性改回 int 后，它才开始按预期工作。

所以，是的，有 2+ 十亿范围未使用是很糟糕的，但事情就是这样。而且，如果您对最终可能会获得十亿多条记录有一点怀疑，那就做多。具有讽刺意味的是，您将有 9,223,372,036,854,775,808 个未使用的数字；）。

【讨论】：

【解决方案3】：

uint 不是CLS compliant，所以一般建议不要在公共API中使用。

【讨论】：

【解决方案4】：

我认为这是个坏主意，因为 int 类型更适合在 .NET Framework 中使用。

【讨论】：

那么您将如何处理超过int.MaxValue 的客户？
@Recycle Bin：如果我有超过 20 亿的客户，那么使用已签名与未签名 int 作为密钥的问题将不会是我最关心的问题。如果是的话，总会有 long/bigint。
我强烈建议反对的一种做法是在任何地方使用短键作为键。我的一个好（而且非常聪明）的朋友曾经这样做过，在高度现实的假设下，一个特定的性能关键表永远不会有任何接近 2^16 的记录。后来进行了几次数据库重构，业务有所增长，而有问题的表正在突破该限制。由于数据量大和密钥传播，一个月需要十几个人将那一列迁移到一个 int。
@Recycle Bin：这是另一种情况，如果问题是关于大量客户，我会回答“是”。