这问题我之前帮朋友做五金产品系统的时候刚好碰到过，两种方案都实际落地过，给你拆解清楚各自的优劣和适用场景：

一、关联表（也就是你说的Pivot Table思路） #

核心是把规格表拆成几张关联的结构化表，典型的表结构大概是这样：

• products：存产品基础信息（id, name, category_id 这类固定字段）
• spec_tables：记录每个产品的规格表元数据（id, product_id, table_name 比如“技术参数表”）
• spec_columns：定义每个规格表的列（id, spec_table_id, column_name, data_type 比如“重量”对应数字类型）
• spec_rows：存规格表的具体行数据，用row_index区分同一表的不同行，column_id关联到具体列（id, spec_table_id, row_index, column_id, value）

优点： #

• 数据完全结构化，支持SQL直接做筛选、聚合，比如要找所有重量>5kg的产品，写个关联查询就行，性能稳定
• 有严格的数据类型校验，能避免把数字存成字符串这种低级错误
• 可以给常用的查询字段加索引，数据量大的时候查询效率比JSON高很多

缺点： #

• 开发和维护成本高，新增一个规格表或者加一列，要操作好几张表，写业务代码的时候也要处理多表关联，逻辑会复杂不少
• 如果产品规格表的列、行数特别多，spec_rows表会变得非常庞大，查询时的关联逻辑会很繁琐，容易写出低效的SQL

二、JSON数据类型存储 #

这种方案就简单多了，要么在products表加一个spec_tables的JSON字段，要么单独建一张product_specs表，每条记录对应一个产品的所有规格表，JSON结构大概长这样：

[
  {
    "table_name": "技术参数",
    "columns": ["尺寸", "重量", "材质"],
    "rows": [
      {"尺寸": "30x20cm", "重量": 2.5, "材质": "ABS"},
      {"尺寸": "40x30cm", "重量": 4, "材质": "PC"}
    ]
  },
  {
    "table_name": "包装规格",
    "columns": ["包装类型", "装箱数"],
    "rows": [{"包装类型": "彩盒", "装箱数": 24}]
  }
]

优点： #

• 开发速度快到飞起，不用管复杂的表关联，新增规格表或者改列直接改JSON结构就行，前端解析也方便
• 灵活性拉满，完全适配不同产品的规格表差异，不管列数怎么变都能存，不用改表结构
• 数据结构直观，看一眼JSON就能明白整个规格表的内容，调试起来省事

缺点： #

• 非结构化数据，SQL查询受限，比如要筛选重量>5kg的产品，得用数据库的JSON函数（比如PostgreSQL的jsonb_extract_path_text），数据量大的时候查询效率会明显下降
• 没有数据类型校验，容易存错值（比如把重量写成“两公斤”这种字符串），后期清理数据会头疼
• 索引不好做，虽然像PostgreSQL的jsonb类型支持GIN索引，但只能针对特定的JSON路径，不如结构化表的索引灵活

三、到底选哪个？ #

给你几个实际的判断维度：

• 如果经常需要对规格数据做筛选、统计、报表（比如后台运营要按规格找产品，做销售分析），优先选关联表方案，长远来看维护和性能更靠谱
• 如果规格表只是用来展示，很少做复杂查询，或者产品规格变化特别频繁（比如电商的定制化产品），选JSON方案，开发成本低，灵活度高
• 折中方案：如果大部分规格是固定的，只有少数字段是可变的，那固定字段存在结构化表，可变部分用JSON存，兼顾两者的优点

举个真实例子：我之前做的五金产品系统，一开始图省事用了JSON存规格，后来后台要做按尺寸、重量筛选的功能，数据量上来后查询慢得要死，最后改成了“固定字段+关联表+少量JSON”的混合方案，效果立马就上去了。

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