2

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

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

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

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

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

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

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

4

1 回答 1

7

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

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

于 2016-12-06T17:39:49.857 回答