本文讲解如何正确设计具有单一主键、允许多行关联同一业务单号的传输表结构，重点澄清主键约束与业务逻辑的区别，并提供符合数据库范式的设计方案。
本文讲解如何正确设计具有单一主键、允许多行关联同一业务单号的传输表结构，重点澄清主键约束与业务逻辑的区别，并提供符合数据库范式的设计方案。
在数据库设计中，“一个传输单号（transmittal_id）对应多条产品记录”是典型的一对多关系，但绝不能将 transmittal_id 直接设为表的主键（PK）——因为主键必须满足唯一性（UNIQUE）和非空（NOT NULL）约束，而多行共享同一 transmittal_id 违反了唯一性要求。
✅ 正确做法：引入独立代理主键 + 业务外键组合
应将 transfer 表设计为：
CREATE TABLE transfer (
id BIGINT PRIMARY KEY AUTO_INCREMENT, -- 代理主键（技术主键，唯一且非空）
transmittal_id INT NOT NULL, -- 业务单号（逻辑标识，可重复）
product_id VARCHAR(20) NOT NULL,
product_name VARCHAR(100),
product_quantity INT DEFAULT 0,
-- 外键约束（如关联 products 表）
FOREIGN KEY (product_id) REFERENCES products(id),
-- 可选：为查询性能添加复合索引
INDEX idx_transmittal_product (transmittal_id, product_id)
);? 关键说明：
- id 是真正的主键，保证每行物理唯一；
- transmittal_id 是业务主键（business key），用于标识同一传输单下的所有明细行，允许重复；
- 若需确保“每个 transmittal_id 至少有一条记录”，应在应用层或通过存储过程控制，不可依赖主键约束实现；
- 如需强制 transmittal_id 的合法性（例如必须存在对应 header 记录），可添加外键指向 transmittal_header 表（推荐分离 header/detail 模式）：
-- 示例：头表（存储传输单基本信息）
CREATE TABLE transmittal_header (
transmittal_id INT PRIMARY KEY,
created_at DATETIME DEFAULT NOW(),
status ENUM('draft', 'sent', 'archived') DEFAULT 'draft'
);
-- 明细表外键引用头表
ALTER TABLE transfer
ADD CONSTRAINT fk_transmittal
FOREIGN KEY (transmittal_id) REFERENCES transmittal_header(transmittal_id);⚠️ 注意事项：
- 不要试图用 NULL 填充 transmittal_id（如示例中空单元格）来“绕过”主键限制——这既违反实体完整性，也破坏查询语义；
- 所有 transmittal_id 值必须明确赋值，空值应视为数据错误或未提交状态，建议用 DEFAULT 或应用层校验拦截；
- 查询某传输单全部明细时，使用 SELECT * FROM transfer WHERE transmittal_id = 1; 即可高效获取全部关联行。
总结：数据库主键 ≠ 业务单号。合理区分技术主键（保障数据完整性）与业务键（表达业务语义），是构建可扩展、易维护关系型模型的基础。
