在SQL Server上存储时区

时间:2016-12-06 12:49:55

标签: c# sql-server timezone nodatime iana

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

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

我看到两种不同的方法:

  1. 只需将IANA标识符与每个位置一起存储为字符串。
  2. 将所有IANA标识符存储在单独的表中,并使用外键链接到该表。
  3. 第一种解决方案可能是最简单的,因为它可以轻松地允许新的标识符,并使数据紧密结合在一起。 但是,它确实存在使用大量空间的缺点。

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

    正如我写的那样,我想知道,是否甚至可以为SQL Server创建自定义时区UDT,其中时区可以保存并加载为字符串标识符,但可以更有效地存储以用户隐藏的格式。

1 个答案:

答案 0 :(得分:4)

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

通过规范化查找表可以节省的几千字节存储通常不值得加入,恕我直言。但是,与任何权衡一样,您应该评估这两个选项,以查看哪种方案更适合您的方案。使用查找表不一定错误