药房电商平台产品目录优化：EAV与PostgreSQL JSONB选型咨询

生产环境可管控性：EAV vs PostgreSQL JSONB #

基于长期可维护性和复杂过滤需求（如活性成分+剂量+品牌组合查询），PostgreSQL JSONB方案更易管控，原因如下：

• EAV模型的痛点：多属性过滤需要多次关联entity、attribute、value三张表，数据量达到十万/百万级后，关联查询的性能衰减非常明显；新增品类属性时需要新增属性记录、调整查询逻辑，维护成本随品类扩张线性上升，schema级校验的优势会被复杂的关联逻辑抵消。
• JSONB的优势：借助GIN索引可以高效支持多属性组合过滤（示例查询：WHERE properties @> '{"active_ingredient": "布洛芬", "dosage": "200mg", "brand": "芬必得"}'），读取数据时单次查询即可获取所有属性；新增品类属性无需修改表结构，仅需调整应用层的校验和业务逻辑，长期维护的灵活性和成本控制更优。

JSONB在医疗系统的无schema风险 #

JSONB的无schema特性确实存在不可忽视的风险：

• 数据一致性风险：若应用层校验失效，不符合规范的数据（如药品剂量格式错误、必填属性缺失）可能直接存入数据库，而医疗类数据对准确性要求极高，错误数据可能引发合规问题（如违反药品监管要求）或业务风险（如用户误购不符合需求的药品）。
• 数据治理难度：无schema的结构会导致同品类数据的属性字段可能存在差异（如不同批次的药品记录缺少某个属性），后续的统计分析、数据迁移、问题排查都会变得复杂，增加长期维护的隐性成本。

Zod/Joi等应用层校验是否足够？ #

Zod/Joi这类应用层校验工具可以满足核心需求，但需配套兜底机制：

• 校验能力层面：这类工具能实现严格的schema校验，比如定义每个品类的必填字段、数据格式（如剂量必须为数字+单位）、枚举值（如品牌的可选范围），可以在数据写入前拦截绝大多数错误。
• 配套机制补充：
  • 避免绕过校验：确保所有数据库写入操作都经过应用层校验，禁止直接通过数据库客户端或未校验的接口写入数据。
  • 数据库兜底校验：针对医疗核心属性（如活性成分、剂量），可以在PostgreSQL中添加CHECK约束，验证JSONB字段必须包含这些字段且格式合法；或通过触发器实现简单的校验逻辑，作为应用层校验的最后一道防线。
  • 定期数据审计：定时扫描JSONB字段，排查不符合校验规则的数据，及时修正或清理，避免错误数据积累。

额外建议 #

对于高频用于过滤、排序的核心属性（如品牌、活性成分），可以将其单独抽成普通数据库列，结合JSONB存储非核心的个性化属性，兼顾查询性能和灵活性。

内容的提问来源于stack exchange，提问作者منصور انور