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

Question

有什么利弊？我们何时应该拥有它们以及什么时候不应该？

更新

使用RepositoryFactory生成的更新SP自动中的注释是什么？是否必须对上面的列不存在做任何事情？

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

Answer 1

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

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

有关您的数据的different schemes for keeping historic information的详细信息，请参阅维基百科。您提出的方法类似于该页面上的Type 3，并且存在同样的缺点，即仅记录有关上次更改的信息。我建议你也阅读其他一些方法。

Answer 2

我只能说数据（或完整的审计表）帮助我找到导致重大数据问题的原因。只需一次使用即可说服您花费额外的时间来保持这些字段的最新状态。

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

Answer 3

拥有它们几乎没有任何缺点，所以如果有机会你需要它们，那就添加它们。

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

• 实际上，它们对SELECT使用现代硬件的性能几乎没有影响，并且正确指定了SELECT条款
• 写入性能可能会产生轻微的影响，但这只会成为OLTP类型系统中的一个问题，而这正是您真正想要这些列的情况
• 如果您在这样的位置添加这样的列是性能方面的交易破解者，那么您可能会考虑从SQL数据库转移作为存储平台

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

Answer 4

某些DBMS提供了自动捕获此信息的其他方法。例如Oracle闪回或Microsoft更改跟踪/更改数据捕获。这些方法还捕获了比最新修改日期更多的细节。

Answer 5

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