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

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

相反,这是一个很大的问题,还有很多其他的缺点。

当您使用临时表(至少在sql server中)时, UPDATE 操作(即使数据保持不变)会导致在历史表中生成一个副本(当然,在hood下,这可能是一个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 列和你有 无效的 那么,历史表中的值就卡住了——至少在编写一个数据转换步骤以向历史表提供有效数据之前——这基本上是在为自己创建更多的工作,而没有什么收获。

另外,不要将时态表与不可变表混淆,只追加数据存储(如比特币区块链),虽然它们共享相似的设计目标(除了真正的不可变),但它们存在的目的是解决不同的问题,如果您考虑以太坊区块链的大小要求和缩放问题(目前超过1万亿字节),那么这应该是再告诉你一个为什么这可能不是个好主意。

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

……即使保存在历史表中的所有历史记录,您希望它做什么?你…吗 真的? 需要跟踪每一个正确的排版和小的,无关紧要的变化?您的用户对需要手动审核更改以确定哪些更改有意义或没有意义有何反应?

简而言之:

• 如果你的桌子设计将来不会有太大的变化…
• 很少有小的更新…
• 或者定期进行大的更新,你需要一份审计记录
• ……然后尽可能使用临时表。
• 如果不是,那么你只是在为自己创造更多的未来工作,而没有什么收获。