我不是开发人员（因此请带一点心思），但是想象一下您在销售订单项目级别上有一些自定义字段。 然后，如果在更新这些字段的自定义程序中使用了这些字段，则这些字段的顺序，长度和位置对于通过BAPI_SALESORDER_CREATEFROMDAT2和类似的FM正确更新它们很重要。

如果添加新的 最后的字段-这意味着自定义程序不必调整，仅当我们必须使用任何新添加的字段时。 如果您在程序中使用的字段之间添加字段，我认为这意味着重新测试和调整程序。

如果您有大量的自定义开发，则可能不愿意对每个程序进行调整和重新测试。 可能会受到影响的单个程序。 商业用户可能会抱怨他们需要额外的时间，此外，您还必须将测试时间添加到变更请求估算中，这在与变更发起人进行讨论时很难辩护。

SE11只是一个界面，它将显示DB字段（SE11和DB中的字段可能具有相同的顺序-这取决于表的类型）。 Oracle DB没有选择在两者之间添加字段的选项。 （使用ALTER命令，我们只能在表末尾添加字段，这可能是在表末尾显示所有自定义字段的原因之一）

我认为这是必要的预防措施 ，以降低风险，因为最终的应用程序可以以统一的方式存储表行的所有列：

• 表记录（在表DBTABLOG的LOGKEY和LOGDATA列中）
• 可能是更新功能模块（SM13）的参数值。 我完全不知道SAP如何处理表结构的更改，但恐怕他们根本不检查（？）
• 表是否是启用RFC的函数的参数的一部分 模块，任何外部应用程序都必须在本地存储表的结构-在末尾添加该列将减少出错的风险。
• 与失败的启用了RFC的Transactional/Queued/Background RFC功能模块相同。
• 其他？

IDoc也是元素的示例，其元素必须在段的末尾添加，因为IDoc段以平面方式存储（在SDATA列中）

还有一些ABAP程序对带有静态定义的列的结构或表执行SELECT *（以正确的顺序在BEGIN OF之后是表的每一列）进行选择的风险 而不是使用整个表（TYPE TABLE OF表名）进行键入。

在数据库级别，我认为在表末尾添加一列与在mi中添加一列没有区别 闲逛 但是谁知道...

Sandra Rossi SAP重组了数据库 使用数据库实用程序（SE14）创建表，并且在激活表时将调用它。 我的详细知识来自1997年至2003年的时间范围，现在可能有所不同-那时，当SE11中对数据库表定义进行更改时，DB Utility会将新的SE11布局与现有的本机SQL布局进行比较，并视情况而定。 在使用的本机数据库上，将采用以下两种路径之一：

1. 使用本机DDL修改表的目录（将数据操作留给本机SQL）； 或
2. 卸载表，删除旧结构，使用本机DDL创建新结构，然后将表重新加载到新结构（从而调整数据库表）。

对于OP的问题，APPEND结构通常会将新的自定义字段添加到物理表定义的末尾。 如果SAP将新字段添加到表中，则将这些字段添加到该组合定义的末尾。 如果创建了第二个APPEND，则这些字段将添加到该字段的末尾。 最后，结果将如下所示（取决于所使用的本机数据库）：

在任何ABAP程序中，都将使用数据字典定义，并且DB Utility将执行必要的体操操作，以使代码看不到差异。

注意：这是在ABAP程序中使用本机SQL会出现问题的另一个原因。