关于两属性（DeliveryPerson、DeliveryTime）数据表的3NF规范化实现及无主键数据表合理性的咨询

首先肯定告诉你，这个表完全可以规范化到3NF，核心是先确定合适的主键——毕竟关系数据库里，主键是保证数据唯一性的基础，也是满足范式的前提。咱们分两种场景来梳理：

场景1：同一配送员同一时间仅完成一次配送 #

如果你的业务规则里，同一个配送员在同一个时间点只会完成一笔配送，那直接用复合主键(DeliveryPerson, DeliveryTime)就可以。这时候表的所有字段都是主键的组成部分，不存在非主属性，自然满足3NF的要求（3NF要求消除非主属性对主键的传递依赖，这里没有非主属性，完全符合）。

场景2：同一配送员同一时间可能完成多次配送 #

要是存在同一配送员在同一时间送多笔订单的情况（比如一次送了3个包裹，分开记录），那DeliveryPerson + DeliveryTime就没法唯一标识单条记录了。这时候建议新增一个独立的主键字段，比如DeliveryID（可以用自增整数、GUID这类唯一标识）。

最终表结构会是：

• DeliveryID（主键，唯一标识每一条配送记录）
• DeliveryPerson
• DeliveryTime

这时候检查3NF：

• 所有非主属性（DeliveryPerson、DeliveryTime）都完全依赖于主键DeliveryID，不存在部分依赖；
• 没有非主属性传递依赖于主键的情况，完全符合3NF的要求。

关于无主键数据表的合理性 #

非常不推荐在数据库中使用无主键的表，甚至可以说这种设计是不合理的，原因主要有这几点：

• 数据操作风险高：没法唯一定位单条记录，更新、删除时很容易误操作，比如想删除John在某一天的某一笔配送，结果把所有同时间的记录都删了；
• 性能瓶颈：数据库引擎没法针对无主键的表做有效的索引优化，数据量变大后查询速度会急剧下降；
• 破坏数据完整性：关系数据库的核心是保证数据的一致性和完整性，无主键的表无法建立外键约束，后续关联其他表（比如配送商品表、客户表）时很容易出现数据混乱；
• 违反设计原则：主键是关系模型的基础，每个实体（这里的每一条配送记录）都应该有唯一标识，这是行业通用的设计规范。

内容的提问来源于stack exchange，提问作者Martingale