所有数据库表中 CreatedDate 和 ModifiedDate 列的优缺点答案

【问题标题】：Pros and Cons for CreatedDate and ModifiedDate columns in all database tables所有数据库表中 CreatedDate 和 ModifiedDate 列的优缺点
【发布时间】：2011-03-02 14:48:27
【问题描述】：

有什么好处和坏处？我们什么时候应该拥有它们，什么时候不应该拥有它们？

更新

使用 RepositoryFactory 自动生成的更新 SP 中的此注释是什么？上面的列不存在是否与它有任何关系？

--The [dbo].[TableName] table doesn't have a timestamp column. Optimistic concurrency logic cannot be generated

【问题讨论】：

Why do we need Audit Columns in Database Tables?的可能重复

标签： mysql sql-server database database-design

【解决方案1】：

拥有它们几乎没有任何缺点，因此，如果您有任何需要它们的机会，请添加它们。

人们可能会提到性能或存储问题，但是，

实际上，现代硬件和正确指定的SELECT 子句对SELECT 的性能几乎没有影响
可能会对写入性能产生轻微影响，但这可能只会在 OLTP 类型的系统中引起关注，而这正是您通常需要此类列的情况
如果您正处于添加这样的列在性能方面会破坏交易的地步，那么您可能会考虑从 SQL 数据库作为存储平台转移

对于CreatedDate，我几乎总是将其设置为默认值GetDate()，所以我不必考虑它。在构建我的架构时，我将添加这两个列，除非它是一个没有用于管理它的 GUI 的查找表，因为我知道如果手动修改数据不太可能保持最新。

【讨论】：

您确实需要一个触发器来维护 lastmodifieddate。并且最好正确编写以处理多个记录更新。如果您走这条路线，并且数据可用，请同时添加用户或应用程序。如果您有多个应用程序接触您的数据，那么很高兴很容易看到哪个应用程序放入了那个糟糕的记录。如果它是一个自动化过程，那么您就会发现一个错误。如果它是人类，你可能需要知道重新训练或解雇。

【解决方案2】：

如果您不需要需要有关数据的历史信息，添加这些列将不必要地填充空间并导致页面上容纳的记录减少。

如果您确实或可能需要历史信息，那么这可能还不足以满足您的需求。您可能需要考虑使用不同的系统，例如 ValidFrom 和 ValidTo，并且永远不要修改或删除任何行中的数据，只需将其标记为不再有效并创建一个新行。

有关different schemes for keeping historic information 的有关您的数据的更多信息，请参阅维基百科。您提出的方法与该页面上的Type 3 类似，并且具有相同的缺点，即仅记录有关最后更改的信息。我建议您也阅读其他一些方法。

【讨论】：

根据我的经验，最好从一开始就添加它们。你认为你不需要它们，直到你的老板在你喝咖啡之前问你“谁做的，什么时候做的”
我从事数据库工作已有 20 多年了。如果你没有这些领域，你将在未来被烧毁。这些是您以后不想添加的关键领域。用完的空间太小了，值得。对于查找表，它甚至可能会有所帮助（该选项何时添加到查找中？）

【解决方案3】：

一些 DBMS 提供了其他方法来自动捕获此信息。例如 Oracle Flashback 或 Microsoft Change Tracking / Change Data Capture。这些方法还捕获更多细节，而不仅仅是最新的修改日期。

【讨论】：

除了从我的角度来看，Microsoft Change Tracking / Change Data Capture 对于真正的审计毫无用处，因为它们会刷新缓存。上次修改日期可能是过去 5 年。

【解决方案4】：

该列类型时间戳具有误导性。它与时间无关，它是rowversion。广泛用于乐观并发，example here

【讨论】：

【解决方案5】：

我只能说，数据（或完整的审计表）帮助我找到了造成重大数据问题的原因或原因。只需要一种用途就可以说服您花额外的时间使这些字段保持最新状态是件好事。

我通常不会对仅通过单个自动化过程填充且没有其他人对该表具有写入权限的表执行此操作。通常用户通常也无法更新的查找表不需要它。

【讨论】：