SCL-90 有 90 道题、9 个因子，存一份答卷时摆在面前的第一个选择，就是把 90 个答案铺成一行的宽表，还是拆成 90 行的长表。这个选择看着只是表结构问题，却会一路影响到计分、改题和数据导出，等量表数量上来、答卷积累多了，当初随手定下的存法就会变成很难回头的地基。
宽表：一行一份，读起来直接
宽表是一份答卷占一行，每道题一个字段。取一个人的完整作答只要读一行，做整体导出也顺手，直观又快。代价在结构僵硬：题目一旦增减，就要改表结构加字段；而且不同量表题量差别很大，90 题的量表和 20 题的量表没法共用一张宽表，平台上量表一多，宽表就会膨胀成一堆各不相同的表。
长表：一题一行，改起来灵活
长表是一份答卷拆成多行，每行记一道题的作答，用答卷 ID 和题目 ID 关联。它的好处正是宽表的短板：所有量表共用同一张作答表，新增量表不用建新表，题目增减也只是多几行少几行，字段结构长期稳定。代价是取一份完整答卷要把几十上百行聚合回来，单份读取和整体导出都比宽表费劲，行数随答卷和题量成倍膨胀，数据量大时索引和分区就得跟上，否则聚合会越来越慢。
计分和导出，才是真正的分水岭
真正决定选哪种的，不是存起来好不好看，而是后面怎么算、怎么导。多因子量表的计分是按因子把对应题目的分数汇总，SCL-90 更要在 9 个因子上分别算均分、再算总分和阳性项目数，长表天然贴合这种“按题聚合”的算法，配上一张题目到因子的映射，一条 SQL 按因子分组就能出结果；宽表则要在代码里硬编码每个因子包含哪几列，改一次因子构成或题目归属就得改一处代码，量表一多维护量陡增。导出的诉求恰恰相反：机构要的常是一人一行、每题一列的宽格式表，长表这时反而要做行转列。
橙星云在存多因子量表时倾向长表加因子映射，让同一套计分逻辑覆盖所有量表，而不必为每张表单独写计分；等到要给机构导出宽格式报表时，再从长表按需拼成宽视图——存的时候用灵活的长表，导的时候临时变宽，两头兼顾。
结论并不是非此即彼：量表种类多、题目常调整、又要统一计分，长表更省心；若只有固定几张量表、几乎不变、且频繁要整表导出，宽表的直接也有它的价值。SCL-90 这种多因子、又常和其他量表同台使用的场景，长表通常是更稳的底座。