Schema 决定是什么；路由决定哪台机器领到作业。
1. 动机
一个逻辑 Entity 可能同时需要标量存储、向量搜索、文本搜索与图遍历。 路由让这些字段住在合适的 Backend 上，同时应用代码保留统一的ws.query(Entity) 表面。
HeavenBase 根据已注册的放置规则、Backend 类型、策略、handler 与精确能力证据进行规划。
它根据 object_id 合并 detached 结果 frame。
2. 从自动放置开始
工作区 Preset 提供实用默认值。debug Preset 为本地开发提供完整且可检查的路由设置。
SparseGramIndex 策略执行反向包含。
显式 gram Backend 仍可用于兼容布局。
3. 显式放置字段
当字段需要特定 Backend 或物理策略时，请使用.store(to=..., strategy=...)。
InlineColumn、JsonField、SideTable、VectorIndex、InvertedIndex、SparseGramIndex、GraphEdge 与 ExternalRef。
多数应用只需在 Provider 选择或性能确实重要时显式放置。
4. 检查放置
MetaSchema 中的 storage 行会公开已编译计划：object_id 的放置是固定的。
HeavenBase 会在需要时复制身份，使分散字段仍可还原成一个逻辑行。
5. 检查执行
6. 理解边界
Backend 写入会被协调，但独立路由的 Backend 不构成分布式事务。 失败的扇出可能需要显式审计、修复或应用协调。 保持小巧的操作模型：- 只定义一次 Entity。
- 从 Preset 开始。
- 仅在能带来可测收益时添加显式放置。
- 在宣称性能前使用
explain()。
总结
- 路由将逻辑 schema 与物理执行分开。
- Preset 覆盖常见放置；
.store(...)表达刻意的例外。 - MetaSchema 展示放置，而
explain()展示实际执行。 - 跨 Backend 事务保证仍是应用层问题。