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

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

有什么理由我不应该把所有的桌子都临时化吗

另外，我知道时态表的空间使用情况，这并不是我所理解的问题

我知道时态表的空间使用情况，这并不是我所理解的问题

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

当您使用时态表（至少在SQL Server中）时，每次

更新

操作（即使数据不变）都会导致在历史记录表中创建一个副本（当然，在后台这可能是一个COW优化的副本，但它仍然是另一个概念实体实例）

第二，根据我个人使用LoB应用程序的经验：对数据库的大多数更改都不够重要，不足以证明创建一行的完整副本是合理的，例如，想象一个有4列的表（

CREATE table People）（名字nvarchar（50）、姓氏nvarchar（50）、地址nvarchar（200）、传记nvarchar（max）

：只要修复了

FirstName

中的键入错误，那么其他列中的所有数据都会被复制，即使

传记

包含4GB的文本数据-即使对其进行了优化，它仍会为导致更改的每个用户操作创建副本

有什么理由我不应该把所有的桌子都临时化吗

根据我的经验，主要的原因是它使更改表模式变得更加困难，因为模式（也称为“表设计”）活动表和历史表的值必须相同：因此，如果您有一个表，其中包含一个

NULL

列，您希望将该列更改为

notnull

列，并且您的历史表中包含

NULL

值，那么您将陷入困境-至少在您编写一个数据转换步骤，为历史表提供有效数据之前是如此-它基本上是为自己创造更多的工作，而收获很少

也不要混淆时态表和不可变的、只附加数据存储（比如比特币块链）——虽然它们共享相似的设计目标（除了真正的不可变性），但它们存在于解决不同的问题中，并且如果考虑到Ethunm块链的大小要求和缩放问题（现在超过万亿字节）那么这应该会给你另一个想法，为什么这可能不是一个好主意

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

…即使您已将所有历史记录保存在历史记录表中，您想要它做什么？您真的需要跟踪每一个更正的打字错误和小的、无关紧要的更改吗？您的用户需要手动审核更改以确定哪些更改有意义还是没有意义

简言之：

• 如果您的桌子设计在未来可能不会有太大变化
• 小的更新很少发生
• 或者定期进行大型更新，您需要审计记录
• …然后尽可能使用时态表
• 如果不是，那么你只是在为自己创造更多的未来工作，几乎没有什么收获
对于SQL中的时态特性，“记录所有更改”不是一个好的用例
系统时间时间特性的用例是当有一个迫切的需求要求您/用户能够轻松、快速地重构时（实际上应该在短引号中）您的数据库在给定时间处于的状态。如果您所拥有的只是过去更改的真实日志，那么这将非常困难、容易出错且成本高昂。但是如果您只需要保留更改日志就足够了，那么就这样做吧（从当前状态和日志中重新创建过去的数据库状态将是困难的、容易出错的，而且代价高昂，但如果没有迫切需要，这不是一个紧迫的问题）

---

还请注意，SQL时态特性还包含业务时间的概念，这是一个不同于系统时间的时间维度。业务时间的目标是保存世界形势的历史记录，系统时间的目标是保存数据库本身的历史记录，即的历史记录e世界形势。
您使用的是哪种产品？“SQL”只是一种查询语言，而不是特定数据库产品的名称（并非所有数据库都支持“时态”表）。请为您正在使用的数据库产品添加一个名称。您使用的是哪种dbms？（非常特定于产品的问题。）添加了2016 sql server标记“道歉汉克斯”，它实际上清除了很多关于行副本的内容，将记住这一点，并且只存储具有少量数据的列。感谢您也清除了默认值。遗憾的是，此响应的基调使性能相关的方面优于其他expSQL中的时态特性提供了强大的表达能力。当您需要保存并积极处理历史数据时，缺乏这种表达能力同样会给开发人员带来巨大的痛苦。请参阅“时间与关系理论”的第一章我想知道你对一个假设的JSON文档存储数据库的看法，它由一个

git

存储库支持，每个更改都会导致一个新的提交。评论空间太短，无法以任何合理的详细程度进行讨论，但我的简短建议是：不要浪费你的时间。你会使用远低于关系型的数据模型，源版本管理系统设计用于处理onl