点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)您好专家 我们正在评估BOPF...
点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)您好专家 我们正在评估BOPF...
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
您好专家
我们正在评估BOPF的临时开发,其中涉及多个表,这些表可以在具有HANA数据库的ERP系统上保存数百万条记录。 但是,由于BOPF坚持将GUIDs(RAW16)作为主键,因此总体上我们对性能存在一些疑问。 (我们尚未确定GUID单独可以解决的用例,例如,合并多个数据库)。
大多数用例涉及对SQL脚本中这些表的动态查询(使用ADBC)。 前端是FPM,我们没有ODATA/SADL用例。
总体而言,我们正在寻找一种可以从BOPF框架的核心功能中受益的解决方案,但是该解决方案具有低内存消耗和高连接性能。
我们当前的感觉是,将GUID用作主键可能会占用更多的内存(存储和处理),并且在GUID上进行Join/Search可能不如非GUID键高效。
-考虑到巨大的数据量/动态数据访问,BOPF是否仍是推荐的框架? (可以通过在其上创建替代键和辅助索引)
-在这种情况下,创建不带GUID的表并使用/BOBF/CL_DAC_TABLE创建业务对象是否理想? (几乎没有关于此的博客,但是它们主要用于旧表,而不是用于临时开发)。
谢谢,
Ajith
最终,您可以决定是否 数据模型对于这个抽象层来说太简单了。
JNN
一周热门 更多>