如何在数据库中表示时间结束？

发布于 2024-12-13 17:36:35 字数 502 浏览 1 评论 0原文

我想知道如何在数据库中表示时间结束（正无穷大）值。

当我们使用 32 位时间值时，明显的答案是实际的 32 位时间结束 - 接近年份 2038。
现在我们使用的是 64 位时间值，我们无法在 DATETIME 字段中表示 64 位时间结束，因为 64 位时代的终结是从现在起数十亿年。

由于 SQL Server 和 Oracle（我们支持的两个平台）都允许长达 9999 年的年份，我想我们可以选择一些“大”的未来日期，例如 1/1/3000。
然而，由于客户和我们的 QA 部门都会查看 DB 值，我希望它是显而易见的，而不是看起来像是有人弄乱了他们的日期算术。

我们只是选择一个日期并坚持下去吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

只涨不跌 2024-12-20 17:36:35

使用最大整理日期，根据您的 DBMS，该日期可能是 9999-12-31。您之所以要这样做，是因为如果您尝试采用“纯粹”方法，例如使用 Null（如某些评论者所建议的那样）或使用永久标志（如 Marc B 所建议的那样），那么基于日期范围的查询将很快变得极其复杂

。最大整理日期意味着日期范围内的“永远”或“直至另行通知”，这使得查询非常简单、自然。它使此类查询变得非常清晰和简单：

查找在给定时间点有效的记录。
... WHERE effective_date <= @PointInTime AND expiry_date >= @PointInTime
查找在以下时间范围内有效的记录。
... WHERE effective_date <= @StartOfRange AND expiry_date >= @EndOfRange
查找具有重叠日期范围的记录。
... WHERE A. effective_date <= B.expiry_date AND B. effective_date <= A.expiry_date
查找没有到期日的记录。
... WHERE expiry_date = @MaxCollatingDate
查找没有有效记录的时间段。
好吧，这个并不简单，但是使用最大整理日期作为终点更简单。请参阅： 这个问题 一个好的方法。

使用此方法可能会给某些用户带来一些问题，他们可能会发现“9999-12-31”在报告或屏幕上令人困惑。如果这对您来说是个问题，那么 drdwicox 关于使用用户友好值的翻译的建议是很好的。然而，我建议用户界面层，而不是中间层，是执行此操作的地方，因为最明智或最合意的可能会有所不同，具体取决于您正在谈论的是报告还是数据输入表单，并且受众是内部的还是外部的。例如，有些地方您可能想要的是一个简单的空白。其他人你可能想要“永远”这个词。其他人可能需要一个空文本框，其中带有一个复选框，上面写着“直到另行通知”。

回复收藏 0 原文

倒数 2024-12-20 17:36:35

在 PostgreSQL 中，时间的结束是“无穷大” 。它还支持“-无穷大”。值“无穷大”保证晚于所有其他时间戳。

create table infinite_time (
  ts timestamp primary key
);

insert into infinite_time values
(current_timestamp),
('infinity');

select *
from infinite_time
order by ts;

2011-11-06 08:16:22.078
infinity

PostgreSQL 至少从 8.0 版本开始就支持“infinity”和“-infinity”。

您可以通过使用 dbms 支持的最大日期来模仿这种行为，至少部分地如此。但最长日期可能不是最佳选择。 PostgreSQL 的最大时间戳是 294,276 年的某个时间，这肯定会让一些人感到惊讶。（我不喜欢让用户感到惊讶。）

2011-11-06 08:16:21.734
294276-01-01 00:00:00
infinity

这样的值可能更有用：“9999-12-31 11:59:59.999”。

2011-11-06 08:16:21.734
9999-12-31 11:59:59.999
infinity

这并不是 9999 年的最大值，但数字对齐得很好。您可以将该值包装在 infinity() 函数和 CREATE DOMAIN 语句中。如果您从源代码构建或维护数据库结构，则可以使用宏扩展将 INFINITY 扩展为合适的值。

In PostgreSQL, the end of time is 'infinity'. It also supports '-infinity'. The value 'infinity' is guaranteed to be later than all other timestamps.

create table infinite_time (
  ts timestamp primary key
);

insert into infinite_time values
(current_timestamp),
('infinity');

select *
from infinite_time
order by ts;

2011-11-06 08:16:22.078
infinity

PostgreSQL has supported 'infinity' and '-infinity' since at least version 8.0.

You can mimic this behavior, in part at least, by using the maximum date your dbms supports. But the maximum date might not be the best choice. PostgreSQL's maximum timestamp is some time in the year 294,276, which is sure to surprise some people. (I don't like to surprise users.)

2011-11-06 08:16:21.734
294276-01-01 00:00:00
infinity

A value like this is probably more useful: '9999-12-31 11:59:59.999'.

2011-11-06 08:16:21.734
9999-12-31 11:59:59.999
infinity

That's not quite the maximum value in the year 9999, but the digits align nicely. You can wrap that value in an infinity() function and in a CREATE DOMAIN statement. If you build or maintain your database structure from source code, you can use macro expansion to expand INFINITY to a suitable value.

回复收藏 0 原文

淡淡離愁欲言轉身 2024-12-20 17:36:35

有时我们会选择一个日期，然后制定一项政策，该日期绝不能未经过滤。执行该策略最常见的地方是中间层。我们只是过滤结果，将“神奇”的结束日期更改为更容易接受的日期。

回复收藏 0 原文

扮仙女 2024-12-20 17:36:35

代表“直到永恒”或“直到进一步通知”的概念是一个不确定的命题。

关系理论正确地说，不存在空之类的东西，因此您必须将其分为两部分：一部分包含已知结束日期/结束时间的行，另一部分包含已知的行结束时间尚不清楚。

但是（就像有一个空值一样）将表分成两部分也会使您的查询编写变得混乱。视图可以在一定程度上容纳只读部分，但更新（或在视图上写入 INSTEAD OF）无论如何都会很困难，并且可能会对性能产生负面影响（无论如何）。

让 null 表示“结束时间未知”将使更新变得“更容易”，但是读取查询会因您需要的所有 CASE ... 或 COALESCE ... 构造而变得混乱。

在您想要从 DATETIME 中“提取”DATE 的所有情况下，使用 dportas 提到的理论上正确的解决方案会变得混乱。如果手头的 DATETIME 值是“（可表示的）时间的结束（如您所说，从现在起数十亿年）”，那么这不仅仅是对该 DATETIME 值调用 DATE 提取器函数的简单情况，因为您还希望该日期提取器为您的情况生成“可表示日期的结尾”。

另外，您可能不希望在用户界面中将“缺席时间结束”显示为值 9999-12-31。因此，如果您在数据库中使用时间结束的“实际值”，您将面临一些工作，以确保该值不会出现在您的 UI 中的任何位置。

很抱歉不能说有办法避免所有混乱。你真正拥有的唯一选择就是最终陷入困境。

回复收藏 0 原文