Forma 常见问题
关于 online DDL、JSONB、MongoDB 与 EAV 最常被问到的几个问题，以及 Forma 的定位：用一份 JSON Schema 串起存储、校验、CRUD API，最终进入湖仓供 OLAP 使用。
Forma 的定位是什么？
Forma 想简化后台开发的全链路：一份 JSON Schema 定义存储格式与校验，驱动热表/EAV 写入，提供前端友好的查询与 CRUD API，再由 CDC 推送到湖仓供 OLAP 使用（系列介绍、第三篇）。
目标不是“再造数据库”，而是让字段变更、类型安全、查询性能和湖仓对接自动落在同一套开发流程里，摩擦尽量小。
数据库已经支持 online DDL，为什么还要 Forma？
online DDL 只解决锁表，并不能消除流程。代码调整、索引设计、回归测试还在，一次字段上线常常要几小时甚至数天；而 AI 的字段变化是每天 10-50 种组合，节奏对不上（见第一篇）。
在 Forma 里，加字段就是更新一次 JSON Schema 元数据：写入路径立即生效，不动表结构和索引，迭代以秒计（第一篇）。
Forma 除了避免 DDL，还改变了什么开发流程？
多数 AI 应用已经在用 JSON Schema 描述 LLM 输出和 API 契约；Forma 复用同一份 Schema 同时做类型校验与存储映射，避免为“AI 侧”和“入库侧”各维护一套模型（第一篇）。
写入与查询由热表 + EAV 统一驱动：哪些字段落到热表的 B-tree 列由 Schema 决定，手写映射随之减少（第一篇）。数据链路则由 CDC 把同一批数据同步到 Parquet/DuckDB 供 OLAP 使用，无需另建一套导数模型（第三篇）。
PostgreSQL 已有 JSONB + GIN/B-tree 索引，问题在哪里？
范围和排序查询对 JSONB 需要表达式索引，那仍然是 DDL（第一篇）。局部更新代价更高：如《写放大：隐性成本》一节所示，JSONB 的一次局部修改会重写整个 blob，WAL 与复制开销随之成倍放大。可移植性也弱，依赖 PostgreSQL 特性，跨数据库或云服务迁移困难（第一篇）。
Forma 用热表的预置类型列加现成 B-tree 索引，字段映射只改元数据，不需要 DDL；EAV 层保持通用 SQL 兼容。
为什么不直接用 MongoDB？
MongoDB 适合无关系的文档型场景；当你需要 SQL JOIN、完整 ACID、成熟的 PostgreSQL 工具链以及低成本冷数据分层时，Forma 更合适（第一篇）。冷数据落在 Parquet/DuckDB，成本和一致性都可控（第三篇）。
EAV 是反模式吗？Forma 如何避坑？
热表把 20% 的高频字段映射为物理列，用 B-tree 支撑范围和排序查询，避免全表扫描（第一篇）。N+1 靠单查询聚合解决：CTE + JSON_AGG 把 101 次往返变成 1 次，第二篇有完整推导。冷热分层再配上一致性保障：DuckDB + Parquet 负责历史，Anti-Join 加 Dirty Set 保证联邦查询零脏读（第三篇）。