在线披萨订单系统：配送员表设计——是否需存储客户地址

首先直接给结论：在绝大多数遵循数据库设计规范的场景下，不需要在Delivery_Boy表中额外添加cust_address字段，下面详细解释原因和特殊情况：

一、遵循第三范式（3NF）的最优方案 #

你的CUSTOMER表已经通过cust_id作为主键存储了cust_address，而Delivery_Boy表已经通过外键cust_id关联到CUSTOMER表。根据数据库第三范式的要求，我们应该避免存储冗余数据——因为cust_address完全依赖于cust_id，重复存储会带来以下问题：

• 数据冗余：同一个客户的地址会在CUSTOMER和Delivery_Boy表中多次存储，浪费存储空间。
• 维护成本高：如果客户修改了地址，你需要同时更新CUSTOMER表和所有关联该客户的Delivery_Boy记录，容易出现数据不一致的情况。

需要获取配送地址时，只需要通过JOIN查询即可：

SELECT 
    db.employee_id,
    db.cust_id,
    db.order_id,
    c.cust_address
FROM Delivery_Boy db
JOIN Customer c ON db.cust_id = c.cust_id;

二、需要添加cust_address的特殊场景 #

如果你的业务存在以下情况，那么可以考虑在**订单表（PIZZA_ORDER）**中添加配送地址字段（而非Delivery_Boy表）：

• 客户下单后可能修改默认地址，但订单的配送地址需要保留下单时的快照（即客户下单时的地址，而非当前地址）。
• 存在临时配送地址的需求（比如客户某次下单要求配送到公司，而非默认家庭地址）。

为什么建议存在订单表而非Delivery_Boy表？因为配送地址是和订单绑定的，一个订单对应一个固定的配送地址，而配送员只是负责执行该订单的配送任务。如果把地址存在Delivery_Boy表，当一个配送员负责多个订单时，会出现不必要的重复存储，不符合设计逻辑。

总结 #

• 常规业务场景：仅保留cust_id即可，通过关联CUSTOMER表获取地址，符合数据库设计规范。
• 特殊业务需求：将配送地址快照存储在PIZZA_ORDER表中，Delivery_Boy表仍通过order_id关联获取地址，避免冗余。

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