无符号 64 位值与 NUMERIC(20,0) 的用户定义类型答案

【问题标题】：User defined type for unsigned 64-bit value vs NUMERIC(20,0)无符号 64 位值与 NUMERIC(20,0) 的用户定义类型
【发布时间】：2011-09-01 19:25:57
【问题描述】：

假设我想创建一个表，其中包含一些我想包含 64 位无符号整数的列。我可以通过几种不同的方式来解决这个问题，其中一些可能无效或有后果：

使用NUMERIC(20,0) 并添加一个检查约束，以确保该值不是负数并且在64 位无符号整数的范围内（即>=0 和
创建一个封装此逻辑的 CLR 用户定义类型（并最终包装一个 System.UInt64）。将类型用于列类型和存储过程参数。这种类型是否会给我更大的能力（例如，通过防止无效值被传递到调用站点的存储过程中）？
重用 BCL System.UInt64 类型。这可能吗？

我正在寻找熟悉 SQLCLR 功能/集成的人来评估我的想法，并就最佳行动方案发表评论。

谢谢

【问题讨论】：

【解决方案1】：

使用 numeric(20,0) 和检查约束来限制 0 <= x <= 18446744073709551615（在编辑时修复）

SQL Server 没有无符号 64 而是整数，因此您必须在客户端中执行一些逻辑以使其显示为 int 而不是十进制

需要检查上限，因为 19E18 大于无符号 64，但对于 numeric(20,0) 是可以的。如果 DB 值在客户端溢出并中断，这可能是不可取的。

如果您决定需要额外的几个零，您可以更改为 numeric (23, 0) 或更高...

【讨论】：

10,000,000,000,000,000,000 呢？这不会进入 bigint SELECT CAST(10000000000000000000 AS bigint)。这适用于SELECT CAST(10000000000000000000 AS decimal(20,0))，小于 2^64-1（无符号 64 位限制）
是的，我之前遗漏了一个数字，这就是为什么它没有问题..数字是要走的路
这并不能回答我的问题，即 SQLCLR 类型是否会更好地工作......
@Michael Goldshteyn：不，不会。 SQLCLR 增加了使用本机 SQL Server 数据类型管理的内容的复杂性。它没有增加任何价值。在我的店里，我们也不能使用 SQLCLR；这可能不适用，但以后可能会影响您。老实说，什么时候可以在没有 CLR 的情况下实现，这不值得讨论。
使用 SQL 原生类型无法高效实现。 numeric(20,0) 类型在比较、计算、索引和空间方面的效率远低于 64 位无符号整数。自定义 CLR 类型是否会为 64 位无符号本机 int 增加足够的开销，从而使其与其他潜在缺陷一起成为一个糟糕的选择，这是我的问题的本质。我们打开了 CLR，所以这不是问题。无论如何，SQL Server 已经在内部将 CLR 用于 hierarchyid 和地理空间类型，无论 CLR 是否打开，所以我不会将我的问题归类为过于荒谬。