Abap 在标准内部表上没有按的排序行为？安全吗？

当在标准的内部表上运行时，没有键规范的

SORT

语句具体做什么？根据：

如果没有使用addition BY输入显式排序键，则内部表itab按主表键进行排序。排序的优先级基于在表定义中指定键字段的顺序。在标准键中，排序根据表的行类型中键字段的顺序排列优先级。如果标准表的主表键为空，则不会进行排序。如果静态地知道这一点，语法检查将生成警告

主表键为：

每个内部表都有一个主表键，它是自定义键或标准键。对于哈希表，主键是哈希键；对于排序表，主键是排序键。这两种表类型都是对其密钥访问进行了优化的密钥表，因此主键具有自己的管理。当您访问单个行时，这些表的键字段是写保护的。标准表也有主键，但相应的访问没有优化，没有单独的键管理，并且键字段没有写保护

为了更好地测量，标准键为：

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

所有这些都让我感到困惑，因为我不确定我是否真的可以依靠基本的

SORT

语句来提供可靠或安全的结果。我真的应该在所有情况下都避免使用它吗？或者如果使用得当，它有什么用途吗

---

进一步说，如果我想从itab运行一个比较所有字段的

删除相邻的重复项

，那么在对itab进行简单的

排序之后，什么时候可以安全地执行此操作。

？如果我在所有字段上都添加了一个键？只有当我有一个包含

clike

和

xsequence

列的内部表时，才没有显式键如果我想执行该DELETE语句，在内部表上运行的最佳排序语句是什么？

在所有情况下都应避免使用不带BY的排序语句，因为它“使程序难以理解并且可能不可预测”（dixit）。我认为如果您没有通过提及

，那么代码检查器中的静态检查会发出警告。您应该使用
按table\u行对itab进行排序，其中table\u行是一个特殊的名称（“伪组件”），意思是“该行的所有字段”

这不是您的问题，但您也可以使用主键和辅键定义内部表，这样您就不需要显式排序-可以与这些键中的任何一个一起使用。
内部表可以具有可以从itab所基于或指定的结构继承的键。如文档所述，
sort
不使用
by
按主键排序，并且假设正确实现了内部表，是安全的

I思考此功能设计为一种动态功能，可与智能表钥匙设计一起使用。如果操作正确，
sort
而不使用
by
可以使您的程序适应未来的表键更改。（因此，如果您的密钥发生了更改，请使用更改进行排序）。以奇怪的方式修改密钥时可能会出现问题

作为经验法则：

程序代码越具体，就越不容易出错（也越安全）。
因此，
sort by key\u id，key\u date
将始终按这两个字段生成相同的排序

应用程序中的动态组件使其更加灵活，但当它们所依赖的东西被修改时，往往会出现（通常很难注意到）bug。
因此，如果您使用前面2个关键字段的示例，则在中间添加1（在2个现有字段之间说“代码> KEY-ISHActudio<／代码>”，排序结果可能以您没有预料到的方式改变。
如果您有一个基于日期进行处理的算法，您的算法可能会因该更改而被破坏

在您使用
删除相邻
的特殊情况下，我将遵循桑德拉·罗西的建议
 还有一种想法：只包含一列的表可以安全地忽略BY子句。在这种情况下没有解释的余地。类似的表格经常出现在BOPF中，在BOPF中，您经常使用标识业务对象中节点的GUI的“列表”。@András官方的一句话更好地证明了这一点：