数据库存储多地址的合理设计方案咨询

完全不需要为地址的每个字段单独创建21个列，也不需要存储两份重复的地址数据，以下是两种可根据业务场景选择的最优方案：

方案1：结构化地址表+关联标识（适用90%以上的常规业务场景） #

• 先单独建一张user_address通用地址表，存储所有地址的结构化字段，参考表结构如下：

CREATE TABLE user_address (
  address_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '地址唯一ID',
  user_id INT NOT NULL COMMENT '所属用户ID',
  recipient VARCHAR(50) NOT NULL COMMENT '联系人',
  phone VARCHAR(20) NOT NULL COMMENT '联系电话',
  province VARCHAR(30) COMMENT '省份/州',
  city VARCHAR(30) COMMENT '城市',
  district VARCHAR(30) COMMENT '区县',
  detail_address VARCHAR(200) COMMENT '详细门牌号/街道信息',
  zip_code VARCHAR(10) COMMENT '邮编',
  tax_id VARCHAR(50) COMMENT '发票税号（仅发票地址需要时补充）',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP
)

• 订单表仅存储两个地址关联ID字段：delivery_address_id、invoice_address_id
• 用户勾选「配送地址与发票地址相同」选项时，直接将配送地址的ID赋值给invoice_address_id字段即可，不会产生任何冗余数据
• 优势：支持用户保存多个常用地址、修改地址时仅需要更新user_address表的单条记录，所有关联的订单数据会自动同步，查询统计效率高

方案2：非结构化JSON存储（适用地址字段灵活多变、需要频繁扩展的场景） #

• 如果你需要的21个地址字段多为自定义非通用字段，不需要单独建列，将所有地址信息序列化为JSON格式，存储在同一个address_info字段中即可
• MySQL 5.7及以上版本原生支持JSON字段的查询、修改和索引，性能完全可以满足常规业务需求
• 勾选地址相同时直接将配送地址的JSON值赋值给发票地址字段即可，维护成本极低

注意：如果后续需要按地址维度做统计分析（比如按城市、区域统计订单量），优先选择方案1的结构化存储，统计效率远高于JSON字段查询

为什么不建议建21个单独列？ #

除了会产生冗余数据外，后续地址字段调整需要修改表结构，维护成本极高，是扩展性极差的设计。

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