我正在创建一个新数据库，并计划使用时态表记录所有更改。存储的数据将每天更新，但每张表最多记录5000条记录
有什么理由不应该使所有表都是临时表吗？
Ps。我知道时态表的空间使用情况，据我所知这不是一个问题
答案 0 :(得分：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进行了优化，它仍会为每个导致更改的用户操作。
有什么理由不应该使所有表都是临时表吗？
根据我的经验，主要原因是由于Active和History表的模式（也称为“表设计”）必须相同，因此更改表模式要困难得多：因此，如果您的表中带有{您想要更改为NULL列的{1}}列，并且您的“历史记录”表中有NOT NULL个值，那么您就被卡住了-至少直到编写一个数据转换步骤来提供具有有效数据的历史记录表-它基本上是在为自己创造更多工作，而几乎没有收获。
此外，请勿将时间表与不可变的仅追加数据存储区（例如比特币区块链）相混淆-尽管它们具有相似的设计目标（真正的不可变性除外），它们的存在是为了解决不同的问题-如果您考虑以太坊区块链的大小要求和扩展问题（到现在已经超过1 TB），这应该使您有了另一个主意，为什么它可能不是一个好主意。
最后，即使Temporal Tables没有这些问题-您仍然需要努力编写主要软件，使其可以本地处理时态数据-而且诸如Entity Framework之类的东西仍然没有支持查询时间数据。
......，即使您已设法将所有历史记录保存在“历史记录”表中，您还想要什么呢？您真的需要跟踪每一个纠正的错别字和微小的无关紧要的变化吗？您的用户对需要手动审核更改以确定有意义或不有意义的需求有何反应？
简而言之：
答案 1 :(得分：1)
“记录所有更改”对于SQL中的临时功能不是一个好用例。
SYSTEM TIME时态功能的用例是当有迫切要求使您/用户能够 轻松快速地 重建（应该在实际上是“吓人的引号”）数据库在给定时刻所处的状态。如果您所拥有的只是过去更改的真实记录，那将是困难且容易出错的，而且代价昂贵。但是，如果您只保留更改日志就足够了，那就这样做（从当前状态和日志中重新创建过去的数据库状态将很困难且容易出错，而且代价很高，但是如果没有这种情况，这并不是紧迫的问题。迫切需要）。
还请注意，SQL时间特性还包含BUSINESS TIME的概念，它与SYSTEM TIME是不同的时间维度。业务时间用于保留世界情况的历史记录，系统时间用于保留数据库本身的历史记录，即 您的 记录的历史记录世界形势。