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

Dam*_*mon 8 sql events database-design duration

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

我所看到的strttime和endtime的优势在于,如果您想在特定时间段内调用所有活动的事件,则不必在该时间段之外查看.

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

Per*_*DBA 10

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

重新发明轮子

整本书都是关于行业巨头关于关系数据库中的时态数据的主题.Codd已经过世了,但他的同事兼合着者CJ Date以及最近的H Darwen在"第三宣言"中继续进行和改进关系模型的工作.关于这个主题的开创性书籍是CJ Date,Hugh Darwen和Nikos A Lorentzos的时间数据和关系模型

有很多人发表意见和个人选择重新CS主题,好像他们选择冰淇淋.这是由于没有接受任何正式培训,因此将他们的CS任务视为地球上唯一遇到该问题的人,并找到了解决方案.基本上他们从头开始重新发明轮子,好像没有其他轮子存在.通过阅读技术资料(不包括维基和MS出版物)可以节省大量的时间和精力.

买现代车轮

时间数据一直是数以千计的数据建模者在RM之后使用并尝试实施良好解决方案的问题.其中一些是好的而另一些则不是.但现在我们有巨人的工作,经过认真研究,并提供解决方案和处方治疗.和以前一样,这些最终将在SQL Standard中实现.PostgreSQL已经有一些必需的功能(作者是TTM的一部分).

因此,我们可以采取那些解决方案和处方,这些解决方案和处方将是(a)面向未来的和(b)可靠的(与目前存在的数千个不太好的时间数据库不同),而不是依赖于个人观点或流行在一些网站上投票.不用说,代码也会更容易.

购买前检查

如果你做一些谷歌搜索,请注意还有非常糟糕的"书籍".这些是在MS和甲骨文的旗帜下发布的,博士是在冰淇淋店度过的.因为他们没有阅读和理解教科书,他们对问题的理解很浅,并且发明了非常不正确的"解决方案".然后他们继续提供大量的解决方案,而不是时间数据,而是他们的"解决方案"中固有的大量问题.你将被锁定在已被识别和唯一的问题; 并实现触发器和各种不必要的代码.任何免费的东西都值得你付出的代价.

时态数据

因此,我将尝试简化时间问题,并从教科书的指导中解释问题的范围.简单的规则,同时考虑了标准化和时间要求,以及您没有预见到的用法.

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

  2. 其次,确保为列和变量使用非常清晰的名称.

  3. 时间数据有三种类型.所有这些都是关于正确分类,以便治疗(计划的和计划外的)很容易(这就是为什么你的问题很好,为什么我提供完整的解释).使用内联日期/时间函数的SQL更简单(您不需要计划的Temporal SQL函数).始终存储:

    瞬间为SMALL/DATETIME,例如.UpdatedDtm

    间隔为INTEGER,清楚地标识列名称中的单位,例如.IntervalSec要么NumDays

    • 有些技术人员认为Interval应存储在DATETIME中,无论使用哪个组件,如(例如)自1900年1月1日午夜以来的秒或月等等.这很好,但需要更多笨重(不复杂)的代码在初始存储中以及何时提取.

    • 无论你选择什么,要保持一致.

    期间或期限.这被定义为两个单独的Instants之间的时间段.存储取决于Period是合并还是析取.

    • 对于合并期间,如在您的事件要求中:使用一个SMALL/DATETIME EventDateTime; 句点的结尾可以从下一行的句点的开头派生,EndDateTime不应该存储.

    • 对于disjunct Periods,在yes之间存在间隙,您需要2 x SMALL/DATETIME,例如.a RentedFrom和a RentedTo.如果它在同一行.

    • 跨行的句点或持续时间仅需要将结尾Instant存储在其他行中.ExerciseStart是Event.DateTime对的X1 Event行,ExerciseEnd是Event.DateTime对的X9 Event行.

因此,作为间隔存储的期间或持续时间根本不正确,不受意见限制.

数据重复

另外,在规范化数据库中,即.如果EndDateTime没有存储(除非不相交,如上所述),存储可以导出的数据将引入更新异常,其中没有.

  • 一个人EndDateTime,你在一个地方有一个真理的版本; 与重复数据一样,您在另一列中有第二个版本的事实:

    • 打破1NF

    • 这两个事实需要在事务上保持(更新),并且存在不同步的风险

    • 由于两个版本的事实,不同的查询可能会产生不同的结果

  • 通过保持科学,很容易避免.返回(单个查询的速度无显着增加)不值得破坏数据的完整性.

对评论的回应

你能否稍微谈谈合取与分离之间的实际差异以及这些概念对数据库设计的直接实际影响?(据我所知,差异,我的数据库中的练习和临时基础是分离的,因为它们是由空格分隔的不同事件......而基础本身将是合取的,因为总有一个值)

不完全的.在你的Db中(据我所知,到目前为止):

  • 所有事件都是瞬间,而不是合并或分离期间

  • 例外是Exercise和TempBasal,为其存储结束Instant,因此它们具有Periods,在Periods之间有空格; 因此它们是分离的.

    • 我想你想要识别更多持续时间,例如ActiveInsulinPeriod和ActiveCarbPeriod等,但到目前为止他们只有一个事件(即时)是致使.
  • 我不认为你有任何合相时期(可能会有,但我很难确定任何.我收回我所说的(当他们是读书时,他们看起来是合相,但我们已经取得了进步).

    • 有关合并期间的简单示例,我们可以使用实际效果,请参阅此时间序列问题.文本和代码可能是有价值的,所以我已经链接了Q/A,但我特别希望你看一下数据模型.忽略这三个实现选项,它们与此上下文无关.

    • 该数据库中的每个Period都是Conjunct.产品始终处于某种状态.任何Period的End-DateTime是Product 的下一的Start-DateTime .


Ric*_*iwi 3

结束 - 开始 = 持续时间。
有人可能会说您甚至可以使用“结束”和“持续时间”,因此任何组合实际上都没有区别。

除了您需要的琐碎内容之外the column included to filter on it,请包括

  • 持续时间:如果需要按执行时间的持续时间进行过滤
  • 开始+结束:如果您需要捕获在某个时间范围内开始和结束的事件