SQLite订单表如何关联多格式收货地址？对应最佳实践是什么？

现有3种方案的优劣势分析 #

• 方案1：订单表新增多可空外键关联不同地址表
  优势：关联逻辑简单，单订单地址查询连表次数少
  劣势：完全不推荐。扩展性极差，每新增一种地址格式就要修改订单表加字段，CHECK约束维护成本随地区数量线性上涨，订单表冗余度会越来越高。
• 方案2：按地区单独创建订单地址关联表
  优势：表结构无冗余，不同地区地址数据隔离清晰
  劣势：查询订单地址前需要先判断地址所属地区再匹配对应关联表，跨地区地址聚合查询复杂度极高，新增地区时既要加新表也要修改全量查询逻辑，仅适合业务完全不扩展服务地区的极小规模场景，通用性极差。
• 方案3：主地址表+分地区子表关联，订单表仅关联主地址ID
  优势：扩展性较好，新增地址格式仅需加对应子表，无需修改订单表，地址数据支持多订单复用。是关系型数据库存储多态结构的行业通用方案
  劣势：需要在主地址表新增address_type字段标记关联的子表类型，SQLite本身不支持多态外键校验，需要业务层保证类型和子表关联的一致性，查询完整地址需要同时连主表和对应子表。

适配SQLite特性的更优方案 #

SQLite原生支持JSON类型，且地址属于写入后极少修改的静态数据，针对这个特性有两个投入产出比更高的可选方案：

方案A：主地址表+JSON扩展字段（优先推荐） #

表结构设计：
master_address主表仅存储所有地区通用的公共字段：

• master_address_id 主键
• country_code 国家/地区码，用于标记地址所属格式规则
• formatted_address 格式化后的完整地址文本，用于前端直接展示
• address_components JSON类型，存储对应地区特有的地址字段，比如美国的apartment_no、非洲的landmark_distance等
  优势：

1. 无需维护大量子表，新增地址格式完全不需要修改表结构，仅需业务层约定不同country_code对应的JSON字段规则即可
2. 查询逻辑极简，订单表仅需关联一次master_address_id就能拿到全部地址数据
3. SQLite对JSON操作支持完善，可通过json_extract()函数直接提取JSON内的字段做过滤、排序，完全满足常规地址检索需求
   适用场景：90%以上的中小业务都适用，只要不需要对地址特有字段做高频复杂聚合查询，该方案的开发和维护成本最低。

方案B：主地址表+键值对属性表 #

如果你的业务需要对所有地址属性做统一的聚合分析，可以采用该方案：
表结构设计：

• master_address主表：存储master_address_id、country_code、formatted_address公共字段
• address_attribute属性表：存储attribute_id、master_address_id、attribute_key（属性名，比如state、landmark_direction）、attribute_value（属性值）
  优势：所有地址属性统一存储，支持任意维度的属性聚合查询，扩展性拉满
  劣势：查询单条地址完整属性需要做行转列操作，写入一条地址需要插入多条属性数据，读写性能比JSON方案低，仅适合有强地址分析需求的场景。

最终选型建议 #

如果你的业务规模不大，未来有扩展服务地区的需求，优先选主地址表+JSON扩展字段方案，完全适配SQLite的轻量特性，开发维护成本最低；如果业务要求强地址字段一致性校验，不需要频繁新增地址格式，可选择你提到的方案3。 #

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