sql中的事件是否首选使用结束时间或持续时间？

我的直觉告诉我，一般来说，开始时间和结束时间比开始时间和持续时间要好，但我想知道不同的方法是否有一些具体的优点或缺点

我看到的strttime和endtime的优点是，如果希望在某个时间段内调用所有活动事件，则不必查看该时间段之外的事件

---

（这适用于在初始输入后不太可能发生太大变化的事件，并且与特定时间相关，如果这会产生影响的话）

这完全取决于您对数据的处理方式。正如您所说，如果您存储了结束时间，则可以按结束时间进行过滤。另一方面，如果您想找到“所有持续时间超过一小时的事件”，那么持续时间将是最有用的

当然，如果需要，您可以随时存储这两个

重要的是：你知道你想如何使用这些数据吗

---

<>编辑：只需添加更多的肉类，取决于您使用的数据库，您可能希望考虑使用视图：仅存储（例如）开始时间和持续时间，但有一个视图，它显示开始时间、持续时间和计算结束时间。如果您需要查询所有三列（无论是一起查询还是单独查询），您将需要检查数据库对索引视图列的支持。这具有方便和清晰的优点，但没有数据冗余的缺点（必须使“备用”列与其他两列保持同步）。另一方面，它更复杂，需要数据库提供更多支持。

结束-开始=持续时间。
有人可能会说，你甚至可以使用结束和持续时间，所以在任何组合中都没有区别

除了您需要

包含的列以对其进行过滤的琐事之外，请包含


持续时间：如果需要按执行时间的持续时间进行筛选
开始+结束：如果您需要捕获在一个时间范围内开始和结束的事件

我不认为这是一种偏好或个人选择。计算机科学是一门科学，我们是编程机器，不是一个敏感的孩子

重新发明车轮

整个书都是由行业巨头们写的，主题是关系数据库中的时态数据。Codd已经去世了，但是他的同事和合著者C J Date，最近H Darwen在第三份宣言中继续推进和完善关系模型的工作。关于这一主题的开创性著作是时态数据&cjdate、hughdarwen和Nikos的关系模型
洛伦佐斯

有许多人把自己的观点和个人选择放在CS主题上，就好像他们在选择冰淇淋一样。这是因为他们没有接受过任何正式培训，因此他们对待CS任务的态度就好像他们是地球上唯一遇到这个问题并找到解决方案的人一样。基本上，他们从头开始重新发明车轮，就好像没有其他车轮存在一样。阅读技术资料（不包括维基百科和微软的出版物）可以节省大量的时间和精力

购买现代车轮

时态数据一直是一个问题，成千上万的数据建模者在RM之后都在努力解决这个问题，并试图实现好的解决方案。有些是好的，有些不是。但现在我们有了巨人的工作，经过认真的研究，并提供了解决方案和规定的治疗方法。与以前一样，这些最终将在SQL标准中实现。PostgreSQL已经有一些必需的函数（作者是TTM的一部分）

因此，我们可以采取这些解决方案和处方，这些解决方案和处方将（a）经得起未来考验，并且（b）可靠（不同于目前存在的数千个不太好的时态数据库），而不是依赖于个人意见或某个网站上的流行投票。不用说，代码也会简单得多

购买前检查

如果你在谷歌上搜索的话，要注意还有一些非常糟糕的“书”。这些都是在微软和甲骨文的旗帜下发表的，由在冰淇淋店度过一生的博士们撰写。因为他们没有阅读和理解教科书，他们对问题的理解很肤浅，并且发明了相当不正确的“解决方案”。然后，他们继续提供大规模解决方案，不是针对时态数据，而是针对其“解决方案”中固有的大量问题。您将被锁定在已确定和唯一的问题中；以及实现触发器和各种不必要的代码。任何免费提供的东西都和你付的价格一模一样

时态数据

因此，我将尝试简化时间问题，并根据您的问题范围，解释教科书中的指导。简单的规则，同时考虑规范化和时间要求，以及您未预见到的用法

首先，对于任何类型的时态列，都要使用正确的数据类型。这意味着DATETIME或SMALLDATETIME，具体取决于所需的分辨率和范围。如果只需要日期或时间部分，您可以使用它。这允许您直接在WHERE子句中使用SQL函数执行日期和时间算术


其次，确保列和变量的名称非常清晰


有三种类型的时态数据。这都是关于正确分类的，这样治疗（有计划的和无计划的）就容易了（这就是为什么你的问题是个好问题，为什么我会提供完整的解释）。优点是使用内联日期/时间函数的SQL更简单（您不需要计划的时态SQL函数）。始终存储：


即时小/日期时间，如UpdatedTM