PostgreSQL存储多语言翻译变长字段的最优方案是什么

三列分长度存储设计的实际开销与缺陷 #

首先直接回答你最关心的存储问题：PostgreSQL不会为NULL的varchar列预留定义长度的存储空间，和你了解的Oracle旧版本预留机制完全不同。
PostgreSQL行结构中，NULL值只会在行头部的空值位图里占1个比特位标记状态，完全不会分配实际存储文本的空间。你设计的表每行仅给short/med/long其中一列赋值时，剩下两个空列不会占用2250字符的预留空间，不存在你担心的空列占空间的问题。
但这个三列设计本身存在明显缺陷，不推荐使用：

• 表关联成本线性增长：你现在查询两个翻译字段就需要对LANGUAGE表做两次自关联，后续如果新增需要翻译的字段（比如活动提示、活动规则），就要多写一次关联逻辑，关联数随翻译字段数上涨，既容易写错SQL，也会带来不必要的查询性能损耗。
• 约束维护成本高：你需要额外写复杂的CHECK约束才能保证“每行仅一个文本列有值”，后续如果调整不同场景的文本长度限制（比如中长文本从50字符调整为100字符），必须修改表结构，灵活性很差。
• 字段命名存在歧义：你当前表中language_id字段实际存储的是翻译条目ID（同一个ID对应英、西等多语言的翻译内容），后续开发人员很容易将其误认为是语言类型的主键，引发关联逻辑错误。
  另外补充：PostgreSQL基于MVCC实现并发控制，行更新时会写入新的行版本，不存在Oracle那种“为了避免更新时行迁移提前预留列空间”的机制，完全不需要靠分多列定长的方式优化更新性能。

varchar长度定义的空间效率对比 #

结论非常明确：

• 定义长度上限为2000的varchar(2000)，和不设长度上限的varchar（即等价于text类型），存储空间没有任何区别。PostgreSQL的变长字符串类型是按实际存入的内容长度分配空间的，和你定义的长度上限完全无关——存10个字符的字符串，不管列定义的上限是50、2000还是无上限，占用的空间都是10字符对应字节数加少量长度记录开销，不会因为上限设得大就多占空间。
• varchar的长度上限唯一作用是做写入时的内容长度校验，和存储效率、查询性能没有关联。你之前担心“短内容配长字段浪费空间”的问题，在PostgreSQL中完全不存在。

更合理的设计参考 #

你完全没必要分short/med/long三个列存翻译内容，可以按下面的思路调整结构，兼顾灵活性和性能：

• 拆分两个基础表，职责分离：
  • 语言字典表：lang (lang_code PRIMARY KEY, lang_name)，单独存所有支持的语言标识，比如english/spanish，不要和翻译内容混存。
  • 翻译内容表：translation (trans_id BIGINT PRIMARY KEY, lang_code REFERENCES lang(lang_code), content TEXT NOT NULL)，用单个TEXT字段存所有翻译内容，不需要按长度分多列。
• 调整EVENT表的关联字段：将原来的event_name、event_description字段改为存翻译表的主键event_name_trans_id、event_desc_trans_id，查询时按传入的语言参数关联翻译表即可，示例SQL如下：

select e.id, name.content as event_name, desc.content as event_description
from event e
left join translation name 
  on e.event_name_trans_id = name.trans_id and name.lang_code = ?
left join translation desc
  on e.event_desc_trans_id = desc.trans_id and desc.lang_code = ?
where e.id = 0

• 长度校验逻辑可以根据业务场景灵活实现：比如事件名称最长50字符、事件描述最长2000字符的规则，既可以在应用层做入参校验，也可以在翻译表增加trans_type字段标记翻译内容的业务类型，通过CHECK约束限制不同类型内容的长度，远比固定三列的设计灵活。

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