如何验证所有可能的 FLOAT(53) 值都转换为唯一的 BINARY(8) 值？

Question

我们的应用程序代码BINARY的一部分出于散列的目的将数据类型转换为 。例如，我们将BIGINT值转换为BINARY(8). 该文档警告说，SQL 服务器版本之间的转换可能会发生变化：

不保证任何数据类型和二进制数据类型之间的转换在 SQL Server 版本之间是相同的。

作为防御，每当我们开始支持新版本的 SQL Server 时，我们都会尝试运行测试以验证我们所有的转换仍然有效。对于类似的事情BIGINT，我们检查转换值的长度以获取 允许的最小值和最大值BIGINT。这希望意味着我们会知道，例如，SQL Server 2019 是否开始要求BINARY(9)拟合BIGINT.

我们如何进行这种类型的分析FLOAT(53)？现在我们认为所有可能的值都映射到适合 a 的唯一值BINARY(8)，但我不知道如何验证它。这可能不像检查数据类型所需的字节数那么简单。例如，TIME数据类型需要 5 个字节存储，但必须转换为 aBINARY(6)以避免错误。也许这无关紧要，但也让我紧张到BINARY无法转换回FLOAT. 我承认我可能把问题想得太多，所以我欢迎框架挑战作为答案。

如何编写代码来验证所有可能的输入FLOAT(53)都不会溢出 aBINARY(8)并且两个不同的FLOAT(53)值不会转换为相同的BINARY(8)值？

Answer 1

记录了BIGINT和FLOAT(53)的大小（以字节为单位）。使任何一个都不能来回转换为 BINARY(8) 将是一个突破性的变化。

您引用的文档是关于转换的细节，这些细节没有记录并且可能会发生变化。例如，此转换中 float(53) 的字节布局可能会改变。因此，如果您将浮点数转换为二进制 (8)，将二进制 (8) 存储在表中，升级 SQL Server，并将二进制 (8) 转换回浮点数，您可能不会得到相同的值。

这些特定类型具有众所周知的字节布局。BIGINT 是一个 8 字节的小端整数，而 float(53) 是一个标准的双精度浮点数。如果其中之一发生变化，那将是非常令人惊讶的。但是其他类型，尤其是基于 CLR 的类型，确实可能会在版本之间更改其布局。