数据库表何时应使用时间戳记?


18

首先要注意的是,我认为这个问题可能属于数据库交换,但我认为它总体上与编程解决方案有关,而不是与数据库有关。如果人们认为那是最好的,它将转向数据库交换。

我想知道何时在数据库表中添加创建和更新的时间戳?

第一个明显的答案是,如果任何业务逻辑需要知道什么时候进行了更新(例如事务完成日期等),则必须将其输入。

但是非业务逻辑案例呢?例如,我可以想到这样的场景:了解行更改的日期时间以帮助进行故障查找是非常有用的,例如某些业务逻辑发生故障并查看相关的数据库行,从而有可能在更新之前确定一行正在更新导致错误的另一行。

在这种用例下,给每个表一个更新并创建时间戳是有意义的(也许最琐碎的枚举表可能不会被应用程序的任何部分更新)。

为每个表提供时间戳肯定是快速停顿数据库的好方法(尽管可能是错误的)。

那么什么时候数据库表应该使用创建和更新时间戳?


2
我想您已经亲自回答了这个问题。一个人只能给出的答案是“取决于情况”。
菲利普2014年

3
实际上,我几乎在每个表上都有时间戳(主要是出于您提到的原因)。据我所知,这对性能没有负面影响,至少对于Web开发中常用的数据库类型而言,可能有30.000篇文章和成千上万的订单(无论如何都需要时间戳)。可能会有一些情况,但是例如我们的ERP系统(Microsoft Navision)在大多数表上也具有这些时间戳。
thorstenmüller2014年

2
您说给每个表加上时间戳肯定是快速停顿数据库的一种好方法,但是您没有说为什么。在几乎每个DBMS中,时间戳记都是一个很小的值-通常为8个字节或更少。除非添加索引,否则可以忽略不计。
罗斯·帕特森

更新时间戳记,因为这给我带来了变化。这意味着您将只拥有最近一次更改记录的时间,您想要的是拥有所有更改的历史记录。
Pieter B

@PieterB保留某些表的历史记录绝对有价值,但我从来没有遇到过要为每个表执行此操作的情况-YMMV。
罗比·迪

Answers:


5

为了更好,更全面地管理数据库,最明智的做法是这样做。

首先,作为开发人员,您更可能希望跟踪数据库事务和/或开发活动,并在涉及数据库时轻松跟踪代码中的错误和错误。

此外,每当您需要跟踪数据库上为统计目的而进行的活动时。

另外,是否经常发生这种情况,即暂时不需要跟踪数据库活动,但是将来很有可能。今天将需要您的时间,但将来会为您带来更多


15

作为既是盗猎者(开发人员)又是游戏管理员(DBA)的人,令我感到惊讶的是,许多人仍然没有看到其中的价值,并认为它膨胀了。

简单的说:

对于添加了记录(但从未更新过)的任何表,例如登录名等,我会考虑添加DATE_CREATED列。

对于添加和更新记录的任何表,我都考虑添加DATE_CREATED和DATE_UPDATED列。

我曾在许多地方工作,这些地方默认将DATE_CREATED和DATE_UPDATED作为设计的一部分包含在每个表中。

对于几天内运行数百万亿行的大型数据库,我们还为一些表添加了一个SOURCE列,用于跟踪哪个数据源导致了更新,例如,第三方数据源,用户更新,DBA修改,数据清理等


6

问题的措辞方式,是您要求提供的清单。我冒着不直接回答您的问题,而是在您应该使用替代解决方案时回答的风险。

我可以想到这样的情况:了解行更改的日期时间以帮助发现故障将非常有用

记录给定记录的所有更新会更有用吗?仅仅知道最近的更新,可能还不够。该日志可以放在单独的表中。在同一个日志文件中跟踪多个表中的更改会更加方便(它不一定是一个表)。这样可以防止对所有表change_dates进行大量联合查询以获取聚合。通过帮助您查看系统中更多事件的记录,这也将有助于解决问题。

另外:您还必须考虑用户。他们可能不会把它当作商业案例,但是当您没有经验的用户或在企业文化中却从未犯过用户错误并希望始终将其归咎于计算机的用户时,任何类型的日志记录都将有助于包括在表上更新日期。在这种情况下,您可能还需要一个Update_UserID字段。


+1这也是一种常见的技术,可以通过表触发器将记录扔到历史记录表中,然后再对其进行增量处理。某些RDBMS(例如Oracle的Flashback功能)还支持使用时间点查询,以便可以检查过去某个时间点的数据状态。
罗比·迪

一个简单的解决方案是将所有更新和表查询保存到日志中吗?
Gaz_Edge 2014年

这是另一种方式,尽管对于具有大量更新频率的表而言,它可能变得笨拙。使它成为外部表可能会解决一些问题……
Robbie Dee 2014年

1

如果满足以下任一条件,则数据库表应包括创建和修改模板:

  1. 该表代表一些用户提供的活动的主要记录。如果用户使用X,并且您同时拥有a Table_X和a Table_Y,它们是的一对多子代Table_XTable_Y则不是主记录,因此不需要额外的字段。
  2. 当您永久,临时或经常需要系统跟踪时。如果您需要检查Table_Y仅在更新时才Table_X更新,则额外的跟踪字段可以提供帮助。

请注意,这些都不是排他的。您可以继续将它们默认添加到任何地方,并且仅在需要进行性能调整时才省略。


0

个人想法:

我在modified列中看不到该值。

created,绝对应该添加到每个数据库表中,除非有特殊的理由不这样做。在那有很多价值。

但是,updated似乎是浪费。为什么不走遍整猪,制作两个数据库表,一个数据库表指定一个文档ID,另一个数据库表指定文档版本。在非常简单的情况下

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

然后选择最新versiondocument你想要的。这样,您不仅可以保存每个修改日期(不仅是最后一个修改日期),而且还可以保留该文档的每个版本。唯一的反对意见确实是硬盘空间,但是可以肯定的是,当您担心它用完了什么硬盘空间时-在大多数情况下,您甚至会对数据的版本化感到烦恼

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.