2020-08-15 18:59发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中） SAP社区您好， 我想知道H... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
SAP社区您好，
我想知道HANA数据库系统是否本机支持表记录的某种版本控制机制？ 我很想知道我是否对此主题有知识。 我想要在表记录上进行某种版本控制的想法。 在我的方案中，我将使用具有特定值的配置表。 当项目不断发展且配置可能会更改时，我希望有一种分支机制，可以在其中跟踪新值或更改后的值。 我很高兴有人知道这个话题。
致谢
弗雷德里克
确实如此。
从HANA 2开始，就提供了系统版本表和应用程序版本表。 更为笼统的术语是临时表 ，但是不要被旧的，糟糕的历史记录表所迷惑-坚持使用系统/应用程序版本表！
关于这一点的提示，如果可能的话：在考虑"版本控制"时，有必要仔细考虑应如何使用不同版本。
仅仅是为了保留更改历史记录吗？ （以查看）还是应该进行"时间旅行"（截至该时间戳记）查询？ 如果是后者，您的数据模型如何确保仅同时处理/同时有效的数据？ 通常，这需要对数据模型的其他部分进行更多更改。 在您的示例中，请考虑一列，该列指示进行更改的用户。 为了启用对USERS表的查找，还可以对用户表进行版本控制，并且可以找到匹配的条目（基于更改顺序或时间戳），或者USER ID是"永恒的"，并且永远不会被重用，因此随着时间的推移也不会模棱两可。
解决"配置历史"问题的另一种方法可以是：
-在修改某些内容后复制整个配置条目，并分配一个新的版本号。
-保留一个标记，该标记的配置当前处于活动状态。
这种方法可以非常简单地使用不同的配置（因为不需要处理各个记录版本），并且 您可以将" copied_from"指示符或每个配置的"先前配置列表"保留下来，然后轻松进行所需的"分支"即可。
当然，这意味着很多"数据重复"，但是对于配置数据，这通常不是数据量问题。
根据我对这两种方法的经验，我可能会选择"更改时复制"方法，因为应用程序开发人员更容易实现他们的"版本控制"思想，并且不需要整体
另一方面，当数据记录时间对于系统来说非常重要，而您希望将其跟踪留给数据库时，临时表就很方便。 考虑一下数据仓库或外部数据输入到系统中的任何地方，并可能在以后的某个时间点进行更新。
干杯，
Lars
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 何必丶何苦呢 的问题《SAP HANA数据库-表记录的版本控制》','https://www.easysap.com/answer/6388/17587.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
确实如此。
从HANA 2开始，就提供了系统版本表和应用程序版本表。 更为笼统的术语是临时表 ，但是不要被旧的，糟糕的历史记录表所迷惑-坚持使用系统/应用程序版本表！
关于这一点的提示，如果可能的话：在考虑"版本控制"时，有必要仔细考虑应如何使用不同版本。
仅仅是为了保留更改历史记录吗？ （以查看）还是应该进行"时间旅行"（截至该时间戳记）查询？ 如果是后者，您的数据模型如何确保仅同时处理/同时有效的数据？ 通常，这需要对数据模型的其他部分进行更多更改。
在您的示例中，请考虑一列，该列指示进行更改的用户。 为了启用对USERS表的查找，还可以对用户表进行版本控制，并且可以找到匹配的条目（基于更改顺序或时间戳），或者USER ID是"永恒的"，并且永远不会被重用，因此随着时间的推移也不会模棱两可。
解决"配置历史"问题的另一种方法可以是：
-在修改某些内容后复制整个配置条目，并分配一个新的版本号。
-保留一个标记，该标记的配置当前处于活动状态。
这种方法可以非常简单地使用不同的配置（因为不需要处理各个记录版本），并且 您可以将" copied_from"指示符或每个配置的"先前配置列表"保留下来，然后轻松进行所需的"分支"即可。
当然，这意味着很多"数据重复"，但是对于配置数据，这通常不是数据量问题。
根据我对这两种方法的经验，我可能会选择"更改时复制"方法，因为应用程序开发人员更容易实现他们的"版本控制"思想，并且不需要整体
另一方面，当数据记录时间对于系统来说非常重要，而您希望将其跟踪留给数据库时，临时表就很方便。 考虑一下数据仓库或外部数据输入到系统中的任何地方，并可能在以后的某个时间点进行更新。
干杯，
Lars
一周热门 更多>