SAP中纯数字业务字段为何采用char/varchar而非int类型存储

• 前导零保留需求：这类业务编码本身是固定长度的标识，前导零是编码的有效组成部分而非冗余格式。比如4位公司代码BUKRS的合法值0001如果存储为整型会自动丢弃前导零变为1，后续业务查询、报表输出、接口对接时都需要额外补零处理，极易出现匹配错误。10位客户编号KUNNR也存在同样的前导零规则。
• 业务扩展兼容性：业务规则并非一成不变，很多企业后续会出现需在编码中加入字母、特殊字符的需求，比如跨国集团的海外子公司代码加入国别首字母标识。如果最初采用整型存储，后续调整需要修改字段类型、全表迁移历史数据，成本极高，字符类型则可以平滑兼容这类调整。
• 规避无意义运算风险：业务编码的核心作用是唯一标识对象，不需要参与加减乘除等数值运算。存储为整型时极易出现SUM(BUKRS)这类完全无效的错误SQL操作，字符类型从数据定义层面就规避了这类不合理操作的可能性。
• 跨系统对接一致性：外围对接系统的编码规则大多采用字符类型，整型存储在跨系统传输时容易出现大数字溢出、格式转换丢失前导零的问题，字符类型可以实现编码值的原样传输，大幅降低对接适配成本。
• 适配NUMC类型的特性：SAP提供的NUMC类型本质是带数字校验的字符类型，既可以在输入层限制仅允许录入数字，又保留了字符类型的所有优势，比整型更适配业务编码场景。

• 业务标识类字段（客户编码、订单编码、组织编码等）无论是否全为数字，优先选择字符类型，禁止使用整型存储
• 固定长度的编码选择定长CHAR类型，长度不确定的编码选择VARCHAR类型，有纯数字校验要求的可以在字段上增加纯数字约束，模拟SAP NUMC的能力
• 仅当字段为需要参与数值运算的计量、统计类字段（如采购数量、金额、年龄等）时，再选择整型、浮点类数值类型

内容的提问来源于stack exchange，提问作者上原英知