确实如此。

从HANA 2开始，就提供了系统版本表和应用程序版本表。 更为笼统的术语是临时表 ，但是不要被旧的，糟糕的历史记录表所迷惑-坚持使用系统/应用程序版本表！

关于这一点的提示，如果可能的话：在考虑"版本控制"时，有必要仔细考虑应如何使用不同版本。

仅仅是为了保留更改历史记录吗？ （以查看）还是应该进行"时间旅行"（截至该时间戳记）查询？ 如果是后者，您的数据模型如何确保仅同时处理/同时有效的数据？ 通常，这需要对数据模型的其他部分进行更多更改。
在您的示例中，请考虑一列，该列指示进行更改的用户。 为了启用对USERS表的查找，还可以对用户表进行版本控制，并且可以找到匹配的条目（基于更改顺序或时间戳），或者USER ID是"永恒的"，并且永远不会被重用，因此随着时间的推移也不会模棱两可。

解决"配置历史"问题的另一种方法可以是：

-在修改某些内容后复制整个配置条目，并分配一个新的版本号。

-保留一个标记，该标记的配置当前处于活动状态。

这种方法可以非常简单地使用不同的配置（因为不需要处理各个记录版本），并且 您可以将" copied_from"指示符或每个配置的"先前配置列表"保留下来，然后轻松进行所需的"分支"即可。

当然，这意味着很多"数据重复"，但是对于配置数据，这通常不是数据量问题。

根据我对这两种方法的经验，我可能会选择"更改时复制"方法，因为应用程序开发人员更容易实现他们的"版本控制"思想，并且不需要整体

另一方面，当数据记录时间对于系统来说非常重要，而您希望将其跟踪留给数据库时，临时表就很方便。 考虑一下数据仓库或外部数据输入到系统中的任何地方，并可能在以后的某个时间点进行更新。

干杯，

Lars

嘿 Lars Breddemann

THX回答了我的问题，这解决了我的知识不足，并使我可以更深入地研究该主题。

致谢

弗雷德里克