2

我遇到了令我惊讶的事情。

我正在使用WinPcap从网络上收集数据。在内部，WinPcap使用 Windows 性能计数器生成其时间戳。我知道它们会发生漂移，但这些时间戳仍然具有精确到微秒级的精度。

如果我将这些时间戳作为datetime值插入到 SQL Server Compact 4.0 数据库中并稍后提取它们，我注意到精度已降至毫秒。

例如，

10:52:19.706084 -> 10:52:19.706000

现在，我从这里读到SQL Server 将datetime类型为 0.000、0.003 或 0.007 毫秒的值舍入。这就解释了正在发生的事情。

现在，该datetime字段使用 8 个字节来存储其数据，4 个字节用于日期，4 个字节用于自午夜以来的毫秒数。但是，如果我调用DateTime.ToBinary()，我会返回一个 8 字节的数字，该数字代表其所有精度的值。事实上，如果我将这个值写入数据库的bigint列中，然后DateTime.FromBinary()在提取该值时调用，我会以相同的精度得到原始值。

这是我要使用的方法，但我还是很好奇：为什么datetimeSQL Server Compact中的原始类型没有使用DateTimeToBinary/FromBinary的存储机制？

编辑：

正如 Aaron Bertrand 正确指出的那样，SQL Compact 不支持datetime2. 此外，datetime2在常规 SQL Server 中使用 6、7 或 8 个字节，而不是 54 个字节。不过，我的基本问题仍然存在。

4

1 回答 1

2

我不知道完整的内部细节或选择背后的动机，但datetime在内部存储为 - 本质上 - 两个 4 字节整数。一个代表日期，另一个代表时间。我怀疑您在后者中失去了一些精度，因为自 SQL Server 的第一个版本以来处理滴答/毫秒的方式，但同样，我不知道低级实现细节。

更多背景信息的相关问题：

为了在不将值移入和移出二进制格式的情况下支持您想要的精度，我建议使用LocalDB，它具有与 Compact 相同的可移植性优势，但没有许多功能限制（例如支持更精确的datetime2类型 -我向你保证需要 6-8 个字节，而不是 54 :-))。

于 2013-08-01T03:29:43.640 回答