在 SQL Server 上存储时区

Question

我正在开发一项全球调度服务，该服务使用不同时区的物理位置。这些时区必须与每个位置一起保存在数据库中。问题是，它们如何最好地存储？

我们目前使用自定义时区表，它将自定义整数 ID 映射到 Microsoft 时区字符串标识符。我希望改为存储 IANA 时区标识符。我们的数据库是一个 SQL Server，使用 Entity Framework 6 在 C# 中访问。我们使用 NodaTime 处理时间。解决方案必须与所有这些技术配合良好。

我看到了两种不同的方法：

1. 只需将 IANA 标识符与每个位置一起存储为字符串。
2. 将所有 IANA 标识符存储在单独的表中，并使用外键链接到它。

第一种解决方案可能是最简单的，因为它很容易允许使用新的标识符并将数据紧密地保持在一起。但是，它确实有使用大量空间的缺点。

第二种解决方案要求我们在每次需要时区时加入时区表 - 这很常见 - 但需要很少的空间。如果需要，必须将新的时区标识符添加到该表中。它还引入了这些神奇的整数 ID（使用的外键），它们可能会被误认为是众所周知的标识符（我们目前有这个问题，其中 ID 已移出数据库并移入代码字典中，而不是数据库中使用）桌子）。

在我写这篇文章时，我想知道是否有可能为 SQL Server 创建一个自定义时区 UDT，其中时区可以作为字符串标识符保存和加载，但可以更有效地存储在用户中- 隐藏格式。

Answer 1

虽然这两种方法都可行，但通常的做法是将 IANA 时区标识符存储为字符串。它们确实是唯一标识符，因此可以将它们视为唯一标识符。 "America/Argentina/ComodRivadavia"是目前最大的字符串，有 32 个字符 - 所以一个varchar(32)就足够了。不过，我通常使用varchar(50)just 来保证未来的安全。

通过规范化到查找表可以节省的几千字节的存储通常不值得连接的性能影响，恕我直言。但是，与任何权衡一样，您应该评估这两个选项，看看哪个更适合您的场景。使用查找表不一定是错误的。