在 ADT 里创建一张 DDIC Database Table 时，表面上看到的工作很简单，无非是定义字段、指定数据类型、设置 Key，再补上几个@AbapCatalog注解。可一旦表真正进入生产系统，情况就完全不同了。一个字段到底能不能使用引用类型，一个 Include Structure 修改后会影响多少张表，为什么LRAW和LCHR必须待在表尾，为什么一张看起来只是结构稍微复杂一点的表会突然无法激活，甚至为什么仅仅修改一个已经有数据的字段名称就可能造成整列数据丢失，这些问题都属于 DDIC Database Table 的结构级技术属性。SAP 对 Database Table 的定义并不是把 ABAP 结构直接原封不动地扔给底层数据库。DDIC 位于 ABAP 类型系统和物理数据库之间，它负责建立一套数据库无关的逻辑模型，再把逻辑类型映射到 SAP HANA 或其他受支持数据库平台上的物理列类型。SAP 官方资料也明确指出，DDIC Database Table 描述的是底层物理数据库表，同时它自己又可以作为 ABAP 中的 Structured Type 使用，并能通过 ABAP SQL 访问。现代 ABAP Cloud 开发里，这些 Repository Object 主要在 ADT 中维护。也正因为中间存在这一层抽象，一张 Database Table 虽然从 ABAP 视角看起来很像一个 Structure，但它受到的限制远远比普通 DDIC Structure 严格。Table Field 看起来只是字段，背后却横跨两套类型系统Dat
