在模型表中处理expires_in类有效期字段的最优方案是什么

首先明确几个方案的对比和适用场景，你可以根据自己的业务需求选择：

1. 维持现有独立字段方案 #

优势 #

• 数据库层面自带类型约束，所有expires_in_*字段都是整数类型、默认值为0，不会出现非法值类型、key拼写错误这类问题
• 条件查询、排序性能更高，比如要筛选所有有效期≥1年的许可证，直接写WHERE expires_in_years >= 1即可，也可以直接给字段加普通索引优化查询
• 代码层面调用逻辑简单，不需要额外解析结构，直接取字段值参与计算即可

劣势 #

• 灵活性不足，后续如果需要新增小时、季度这类新的有效期单位，必须修改表结构添加新字段
• 字段存在冗余，多数许可证一般只会用到1-2个时间单位，剩下的字段值都是0

2. 改用JSONB存储有效期规则 #

你可以把所有expires_in_*的配置统一放到现有的details JSONB字段里，或者单独新增一个expiration_rule JSONB字段存储。

优势 #

• 灵活性极强，后续新增任意时间单位都不需要修改表结构，直接往JSON里新增key即可
• 表结构更简洁，不需要维护大量前缀相同的同类字段

劣势 #

• 失去了数据库层面的类型约束，很容易出现值类型错误（比如存了字符串格式的数字）、key拼写错误这类问题，需要在代码层额外加严格的参数校验
• 条件查询需要解析JSON结构，PostgreSQL下要写WHERE (details ->> 'expires_in_years')::INT >= 1这类语句，性能比直接查独立字段差，要优化查询还需要建表达式索引，维护成本更高
• 代码层面需要额外做JSON解析、key不存在的兜底处理，开发成本比直接取字段高

3. 其他折中替代方案 #

如果以上两种方案都不符合你的需求，还可以考虑下面的实现：

• 单字段+单位枚举：如果你的业务里许可证不会出现「1年3个月」这类多单位组合的有效期，直接加两个字段expire_value: INT、expire_unit: VARCHAR，单位可选day/week/month/year，表结构最简洁
• 冗余总天数字段：如果你的业务不需要精确的自然月、自然年计算（比如统一按1年365天、1月30天换算），可以新增expires_total_days: INT字段，新增/修改许可证时自动把所有时间单位换算成总天数存储，后续计算过期时间直接加总天数即可，计算性能最高

选型建议 #

如果你的业务不会频繁新增有效期单位，也不需要太灵活的自定义规则，优先维持现有独立字段的方案，稳定性和可维护性都是最高的。只有当你的业务对灵活性要求极高、经常要调整有效期规则时，再考虑用JSONB方案，同时一定要做好代码层的校验和异常兜底。

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