在设计ERP（企业资源计划）系统时，许多系统倾向于使用**“编码（Code）”作为主键**，而不是常见的数据库自增整型主键（如 int 或 bigint）。这背后的原因与业务需求、系统集成、可读性和系统扩展性密切相关。虽然编码在生成速度和唯一性控制方面不如整型主键直接，但它所带来的优势却在实际业务中具有更强的适应性。
本文将从以下几个方面系统分析：
一、编码作为主键的常见场景
在ERP系统中，常见的业务主键编码如：
客户编号：
CUST2024060001订单编号：
SO-202406-00001商品编码：
PRD-ABC-001部门编号：
D-0101
这些编码多带有前缀、年月、业务标识等信息，形成结构化、可识别的唯一标识。
二、为什么ERP系统倾向于使用“编码”作为主键？
1. 业务可读性与语义识别
编码往往是对业务含义的抽象表达，让用户一眼能看出其业务归属。
例如：
PO-202406-0001明确表示是 2024 年 6 月的采购订单。
相比之下，整型 ID（如 1023918）完全没有语义价值，无法在用户界面、接口、报表中直接使用。
2. 系统集成与数据传输的稳定性
在跨系统传输（如 MES、WMS、CRM、BI 等）时，编码是天然的稳定标识符：
不会因导出、导入或同步造成错乱；
可以脱离数据库上下文单独识别业务实体；
在接口协议中，编码可作为“天然主键”使用，整型 ID 则往往是数据库内部字段。
3. 不依赖数据库的唯一性规则
在某些 ERP SaaS 多租户架构中，各租户的数据可能存储在不同数据库或 Schema 中。此时整型主键无法全局唯一，编码更容易通过规则生成（如租户号 + 年月 + 自增）实现分布式唯一性。
4. 更好的人机交互
编码便于出现在：
单据打印编号；
客服或操作员电话核对；
移动端扫码识别；
URL 链接或分享。
而 int 主键往往不能直接暴露给用户或前端，增加了开发与维护复杂度。
三、编码的缺点与挑战
1. 生成慢、依赖序列控制
编码通常需要：
加锁或分布式 ID 服务；
日期、前缀、序号的组合计算；
数据库中查询最大值再 +1。
尤其在高并发下，编码生成服务可能成为瓶颈。
2. 重复风险更高
若不加控制（如定时任务清除缓存、系统异常重启等），有可能出现：
同一业务周期重复；
多节点并发生成重复；
手动导入数据冲突。
3. 字段长度与性能问题
编码字段一般使用 varchar(32) 或更大，不如 bigint 索引效率高，尤其在千万级别数据分页和联表关联时，性能劣于整型主键。
四、如何合理设计ERP系统的数据表主键？
以下为推荐的数据表主键设计方案，兼顾性能、稳定性与可读性：
✅ 方案一：整型主键 + 编码字段唯一索引
CREATE TABLE purchase_order (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_code VARCHAR(32) NOT NULL UNIQUE,
...
);
优势：性能高、结构清晰，整型主键用于内部关联，编码用于业务展示与查询。
建议所有业务系统采用这种 “技术主键 + 业务编码” 双字段结构。
✅ 方案二：UUID 主键（或 Snowflake）+ 编码字段
对于云原生、分布式系统，推荐使用分布式主键（如 UUID、Snowflake ID）：
CREATE TABLE sale_order (
id CHAR(32) PRIMARY KEY,
order_code VARCHAR(32) NOT NULL UNIQUE,
...
);
优势：避免依赖数据库自增；可跨节点生成；业务扩展性强。
缺点是主键索引较大，分页效率低。
⚠️ 不推荐方案：仅以编码作为主键
虽然可行，但存在以下问题：
主键太长，影响聚簇索引性能；
主键生成逻辑耦合业务，维护成本高；
无法统一主键策略（不同表的编码结构不一致）；
异构数据库迁移难度大。
五、如何设计编码生成机制？
建议设计为中心化、支持并发、分库无冲突的服务组件：
| 组件 | 描述 |
|---|---|
| 编码规则定义表 | 每个业务类型有独立规则（前缀、长度、是否按天重置等） |
| 编码生成服务 | 独立服务进程，支持 Redis + DB 双重唯一控制 |
| 业务模块调用编码服务 | 每次生成编码前通过 API 调用，统一入口 |
| 缓存优化 | 支持预生成编码批次，减少实时阻塞 |
例如订单编码可以定义为：SO{yyyyMM}{4位流水}，由服务统一生成。
六、总结
| 比较项 | 整型主键 | 编码主键 | 推荐方式 |
|---|---|---|---|
| 性能 | ⭐⭐⭐⭐ | ⭐⭐ | 整型更佳 |
| 唯一性控制 | 自动 | 需额外实现 | 整型更佳 |
| 业务可读性 | 无 | 强 | 编码更佳 |
| 跨系统稳定性 | 弱 | 强 | 编码更佳 |
| 索引占用 | 小 | 大 | 整型更佳 |
| 推荐做法 | ✅ 保留 | ✅ 单独列 | 双字段方案最佳 |
七、前瞻性建议
在现代 ERP 架构中，应当将主键与业务编码解耦，通过架构规范与自动生成机制来确保系统的一致性、可扩展性与性能可控性：
后端按主键管理，前端按编码展示；
所有系统对外接口只暴露编码；
接口文档与数据字典中清晰区分 ID 与 Code 的作用；
编码字段在所有系统中统一命名规范（如
orderCode、customerCode）；