i have a customer who need show his products for customers on website , he have 8 big categories products, and parameters of these products catrgories are vary,
i think , the parameters is important , because, Customers rely on comparing product parameters to find the one that suits them.
so, i need to research the ruby on rails tech, so AI tell me:
| 评估维度 | JSONB（当前方案） | EAV 模型 | STI（单表继承） | 多表方案 |
|---|---|---|---|---|
| 灵活性 | 极高：无需修改表结构即可增减参数 | 高：通过增加行数据来增加属性 | 低：增加属性需执行数据迁移 | 极低：每个分类都需要建表 |
| 查询性能 | 较高：支持 GIN 索引，单表查询 | 较低：涉及大量 Join 操作 | 最高：原生字段，查询最快 | 高：针对特定表查询 |
| 开发难度 | 低：Rails 原生支持，代码精简 | 高：关联逻辑复杂，表单处理难 | 低：标准 Rails 开发 | 中：需处理多种关联关系 |
| 存储效率 | 中：冗余存储 Key 名 | 低：需要多条记录存储一个对象的属性 | 高：数据存储紧凑 | 高：结构化程度最高 |
| 适用场景 | 属性高度动态、快速迭代的电商系统 | 属性定义需要高度标准化且经常变化的系统 | 属性重合度高、类别固定的场景 | 各类实体逻辑完全独立的场景 |
为什么选择 JSONB 方案？
- 开发效率 (Speed)：电商产品的规格参数千差万别（如：空调有 “功率”，冰箱有 “容积”），使用 JSONB 可以在不频繁变动数据库 Schema 的情况下，快速支持新产品的上架。
- 维护成本 (Maintenance)：EAV 模型虽然灵活，但会导致查询语句异常复杂，且在生成列表页面时容易产生 N+1 查询问题。JSONB 方案在保持灵活性的同时，代码逻辑最为直观。
- 性能平衡 (Performance)：本项目使用 PostgreSQL，其对 JSONB 的优化非常成熟。对于本系统的 SKU 规格展示和后台管理，JSONB 的读写性能远超需求上限。
- 前端适配 (Front‑end Friendly)：JSON 格式与前端数据交互具有天然的兼容性，能极大简化动态表单的数据绑定逻辑。
技术应用
- ActiveRecord
store_accessor：在 Sku 模型中，我们利用 Rails 提供的store_accessor :specifications功能，将数据库中的 jsonb 字段映射为模型的虚拟属性，使其操作起来像普通字段一样方便。 - PostgreSQL JSONB：数据库底层使用 jsonb 类型。与普通的 json 不同，jsonb 以二进制格式存储，支持高效查询和索引（如 GIN 索引）。
- 前端动态表单 (Vanilla JS)：在后台管理界面，使用 JavaScript 动态增删 HTML 节点，允许管理员手动输入任意数量的键值对。
- 后端参数预处理：在
Admin::SkusController中增加了process_specifications方法，将前端提交的数组格式数据清洗并转换为哈希结构，以匹配 jsonb 的存储要求。