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

Question

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

我有什么理由不应该将所有表设为临时表吗？

诗。我知道时态表的空间使用情况，据我所知，这不是一个问题

Answer 1

我知道时态表的空间使用情况，据我所知，这不是一个问题

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

当您使用时态表（至少在 SQL Server 中）时，每个UPDATE操作（即使数据未更改）都会在历史表中生成一个副本（当然，在幕后这可能是 COW 优化的副本，但它仍然是另一个概念实体实例）。

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

我有什么理由不应该将所有表设为临时表吗？

根据我的经验，主要原因是它使更改表模式变得更加困难，因为活动表和历史表的模式（也称为“表设计”）必须相同：因此，如果您有一个包含所需列的NULL表更改为一NOT NULL列，并且NULL您的历史表中有值，那么您就会陷入困境 - 至少在您编写一个数据转换步骤来为历史表提供有效数据之前 - 这基本上为您自己创造了更多的工作，但几乎没有什么收获。

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

最后，即使时态表没有这些问题 - 您仍然需要努力编写主要软件，以便它可以本机处理时态数据 - 并且实体框架之类的东西仍然没有内置支持查询时态数据。

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

简而言之：

• 如果您的桌子设计将来可能不会有太大变化......
• 而且小更新很少发生......
• 或者定期发生大型更新并且您需要审核记录
• ...然后继续尽可能使用时态表。
• 如果没有，那么你只是在为自己创造更多的未来工作而没有什么收获。