SQL Server中：多值存入单列列表还是单独建表？

我在SQL Server中有一张存储产品信息的主表，关联子表存储产品各部件的尺寸、工装等特定信息。部分字段（如工装、Cell Size等）存在多值，原本计划采用**选项1（子表存储）**的方案：

选项1：子表存储多值字段 #

此前修订产品时仅覆盖数据、递增版本号并添加变更说明，现在要求为每次修订创建包含产品、部件及尺寸信息的新记录。但选项1会在每次修订时产生大量重复记录，因此考虑选项2（单列存储多值列表）：

选项2：单列存储多值列表 #

选项2虽不符合数据规范化设计，但能大幅减少修订时新增的记录数，且Cell Size等字段99%的场景下仅需整体查看，符合单列存储多值的适用场景。

现有疑问 #

1. 即便子表字段多为tinyint或decimal类型，用varchar()存储列表是否比单独建表占用更少空间？
2. 已知选项2的主要缺点是丢失字段的数据类型、未来若需单独查询需先解析，但目前无法预见此类场景，还有哪些未考虑到的因素？

未考虑的关键因素 #

• 数据一致性风险：手动拼接或解析字符串时易出现格式错误（如多写逗号、数值格式不统一），子表的强类型约束可避免这类问题，多人维护或批量导入数据时出错概率会显著上升。
• 数值操作与统计成本：若后续需对Cell Size做排序、最值统计或规格验证，字符串解析会带来额外开发成本和性能损耗，远不如子表直接使用聚合函数高效。
• 版本追溯精度不足：如果某次修订仅修改某个部件的单个Cell Size，选项2需整列更新并生成新记录，无法精准定位具体变更的Cell；而选项1可仅修改对应Cell的记录，版本追溯更细致。
• 索引优化限制：子表可针对Product ID、Part No、Cell Size等字段建立索引以加速查询；但选项2的字符串字段无法针对单个数值建立有效索引，即便未来有低频查询需求，性能也会很差。
• 跨系统集成复杂度：若后续需将数据同步到MES、PLM等其他系统，这类系统通常需要结构化的数值数据，选项2的字符串列表需额外解析转换，增加集成难度。
• 存储容量的实际差异：不能仅凭行数判断存储占用，decimal类型的存储（如decimal(8,4)占5字节）远小于字符串形式（如"1.0625"占6字节），加上逗号分隔符后，多个数值的总字节数可能接近甚至超过子表的存储开销；同时SQL Server的页存储、行开销等因素也会影响实际占用，建议针对真实数据量做测试对比。

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