3

SORT在标准内部表上运行时，没有密钥规范的语句究竟做了什么？根据文档：

如果没有使用加法 BY 输入显式排序键，则内部表 itab 按主表键排序。排序的优先级基于在表定义中指定关键字段的顺序。在标准键中，按照表的行类型中键字段的顺序进行排序。如果标准表的主表键为空，则不进行排序。如果这是静态已知的，则语法检查会产生警告。

主表键定义为：

每个内部表都有一个主表键，它可以是自定义键或标准键。对于散列表，主键是散列键，对于排序表，主键是排序键。这两种表类型都是优化了键访问的键表，因此主键有自己的管理。当您访问单个行时，这些表的键字段受到写保护。标准表也有一个主键，但相应的访问没有优化，没有单独的键管理，键字段没有写保护。

为了更好地衡量，标准密钥定义为：

内部表的主表键，其在结构化行类型中的键字段均为类字符数据类型和类字节数据类型的表字段。如果行类型包含子结构，则将这些子结构分解为基本组件。如果行类型本身不是表类型，则非结构化行类型的标准键是整个表行。如果没有对应的表字段，或者行类型本身是表类型，则标准表的标准键为空或不包含键字段。

所有这些主要只是让我感到困惑，因为我不确定我是否真的可以依靠基本SORT陈述来提供可靠或安全的结果。我真的应该在所有情况下都避免它，还是如果使用得当，它是否有目的？

通过扩展，如果我想运行 a DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS，在简单之后什么时候这样做是安全的SORT itab.？仅当我在所有字段上都添加了一个键？只有当我有一个带有clike和xsequence列的内部表时才没有显式键？如果我想执行那个 DELETE 语句，在内部表上运行的最佳 SORT 语句是什么？

4

2 回答 2

6

在所有情况下都应避免使用不带 BY 的 SORT，因为它“使程序难以理解并且可能无法预测”（dixit ABAP 文档）。我认为，如果您不提及BY，代码检查器中的静态检查会发出警告。您应该使用SORT itab BY table_linewhere table_line 是一个特殊名称（“伪组件”），意思是“行的所有字段”。

不是您的问题，但您也可以使用主键和辅助键定义内部表，这样您就不需要显式排序 - DELETE ADJACENT DUPLICATES可以与这些键中的任何一个一起使用。

于 2018-10-23T18:19:37.120 回答
0

内部表可以具有可以从 itab 基于或指定的结构继承的键。正如文档所说，sort没有by按主键排序，假设内部表实现正确，这是安全的。

我认为此功能被设计为与智能表键设计一起使用的动态功能。如果做得正确，sort没有by可以让你的程序适应未来的表键变化。（因此，如果您的密钥更改，请使用更改进行排序）。以奇怪的方式修改密钥时可能会出现问题。

根据经验：

您的程序代码越具体，它就越不容易出错（并且更安全）。因此sort by key_id, key_date，这两个字段总是会产生相同的排序。

应用程序中的动态组件使其更加灵活，但是当它们所依赖的东西被修改时，往往会出现（通常很难注意到）错误。因此，如果您在前面的示例中使用 2 个关键字段，则在中间添加 1（假设key_is_active在 2 个现有字段之间），排序结果可能会以您未预料到的方式发生变化。如果您有一个基于日期处理的算法，那么您的算法可能会被该更改破坏。

在你的特殊情况下，delete adjacent我会听从Sandra Rossi 的建议。

于 2018-10-24T07:10:19.210 回答