Forma 常见问题
快速回答关于 online DDL、JSONB、MongoDB 与 EAV 的常见问题，并说明 Forma 的定位：用一份 JSON Schema 串起存储、校验、CRUD API，到最终进入湖仓供 OLAP 使用。
Forma 的定位是什么？
- 简化后台开发的全链路：用一份 JSON Schema 定义存储格式与校验 → 驱动热表/EAV 写入 → 提供前端友好的查询与CRUD APIs → CDC 推送到湖仓供 OLAP 使用（系列介绍、第三篇）。
- 目标不是“再造数据库”，而是让字段变更、类型安全、查询性能和湖仓对接在同一套开发流程里自动化、低摩擦。
数据库已经支持 online DDL，为什么还要 Forma？
- online DDL 只解决锁表，并不能消除流程（代码调整、索引设计、回归测试）；一次字段上线常常要几小时甚至数天，而 AI 的字段变化是每天 10–50 种组合，节奏不匹配（见第一篇）。
- 在 Forma，新字段等于更新 JSON Schema 元数据，写入路径立即生效，不触动表结构和索引，秒级迭代（第一篇）。
Forma 除了避免 DDL，还改变了什么开发流程？
- AI 应用本来就要用 JSON Schema 约束 LLM 输出和 API 契约；Forma 直接复用这一份 Schema 做类型校验与存储映射，消灭重复建模与迁移（第一篇）。
- CRUD：热表 + EAV 统一驱动写入与查询，同一份 Schema 决定哪些字段映射到带 B-tree 的热列，减少手写代码（第一篇）。
- 数据链路：通过 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 更契合（第一篇）。
- Forma 冷数据落在 Parquet/DuckDB，成本/一致性可控（第三篇）。
EAV 是反模式吗？Forma 如何避坑？
- 热表：把 20% 高频字段映射为物理列，B-tree 支撑范围/排序查询，避免全表扫描（第一篇）。
- 单查询聚合：CTE + JSON_AGG 把 101 次往返变 1 次，解决 N+1（第二篇）。
- 冷热分层 + 一致性：DuckDB + Parquet 负责历史，Anti-Join + Dirty Set 保证联邦查询零脏读（第三篇）。