sql - 为什么默认情况下所有表都不是时态表？

Question

我正在创建一个新数据库并计划使用时态表来记录所有更改。存储的数据将每天更新，但每表不会超过 5000 条记录

有什么理由我不应该让所有表格都是临时的？

附言。我知道临时表的空间使用情况，这不是我理解的问题

Answer 1

I am aware of the space usage of temporal tables, this is not as far as I understand a problem

相反 - 这是一个相当大的问题 - 还有许多其他缺点。

当您使用临时表(至少在 SQL Server 中)时，每个 UPDATE 操作(即使数据未更改)都会导致在历史表中创建一个副本(当然，在后台这可能是 COW 优化的副本，但它仍然是另一个概念实体实例)。

其次 - 根据我使用 LoB 应用程序的个人经验:对数据库的大多数更改都不足以证明创建行的完整副本是合理的，例如，想象一个具有 4 列的表( CREATE TABLE People ( FirstName nvarchar(50), LastName nvarchar(50), Address nvarchar(200), Biography nvarchar(max) :每当 FirstName 中的错字被修复时，所有其他列中的数据被复制，即使 Biography 包含值(value) 4GB 的文本数据 - 即使这是 COW 优化的，它仍然为导致更改的每个用户操作创建副本。

Is there any reason I shouldn't just make all tables temporal?

根据我的经验，主要原因是它使更改表架构变得更加困难，因为 Active 和 History 表的架构(也称为“表设计”)必须相同:因此，如果您有一个带有 NULL 列的表想要更改为 NOT NULL 列并且您的 History 表中有 NULL 值，那么您就被卡住了 - 至少在您编写一个数据转换步骤之前，该步骤将为 History 表提供有效数据 - 这基本上是为自己创造更多的工作而很少获得。

此外，不要将临时表与不可变的、仅附加的数据存储(如比特币区块链)混淆——虽然它们具有相似的设计目标(除了真正的不变性)，但它们存在以解决不同的问题——如果你考虑大小要求和扩展以太坊区块链的问题(现在超过 TB)，那么这应该会给你另一个想法，为什么它可能不是一个好主意。

最后，即使 Temporal Tables 没有这些问题——你仍然需要努力编写你的主要软件，以便它可以在本地处理时态数据——像 Entity Framework 这样的东西仍然没有内置支持查询时态数据。

...即使您已设法将所有历史记录保存在 History 表中，您还想要它做什么？您真的需要跟踪每一个更正的错字和微小的、无关紧要的变化吗？您的用户将如何应对需要手动审核更改以确定哪些更改有意义？

简而言之:

如果您的表设计将来可能不会有太大变化...

和小更新很少发生...

或大型更新定期发生并且您需要审核记录

...然后继续并尽可能使用临时表。

如果没有，那么你只是在为自己创造更多的 future 工作而几乎没有什么收获。