Recipe：Using Different Schemas for Tenants
- 官方来源：
examples/recipes/using-different-schemas-for-tenants - 核对日期：2026-05-22
这个示例解决什么问题
如何让不同租户不仅使用不同数据，还使用不同的数据模型目录。
官方示例的核心做法
示例在 cube.js 中定义：
contextToAppId：按租户隔离缓存repositoryFactory：根据securityContext.tenant选择不同 schema 目录scheduledRefreshContexts：分别为不同租户声明刷新上下文
这说明不同租户不仅可能：
- 数据源不同；
- 连语义模型本身也可能不同。
这说明了什么
1. 多租户不仅有“同模型不同数据”，也有“不同模型不同数据”
某些大客户场景里，字段、表、甚至业务定义都可能存在差异。
2. 模型仓库本身也可以按租户动态切换
这对复杂 B2B SaaS 很重要。
3. 刷新任务也必须租户化
示例里的 scheduledRefreshContexts 很关键，否则不同租户的预聚合不会被独立刷新。
适合迁移的业务场景
- 大客户专属 schema；
- 不同地区产品版本差异较大；
- 平台型产品允许客户扩展专有字段；
- 兼容历史租户模型与新租户模型并存。
实战建议
- 不要在一个超大统一模型里硬编码所有租户特例；
- 评估“共享模型 + 局部差异”与“完全分目录”的维护成本；
- 刷新、缓存、部署、测试都要按租户考虑；
- 这种模式很强，但复杂度也明显更高。
和教程哪章搭配最好
一句话总结
这个 recipe 的核心价值是：展示 Cube 不仅能按租户切换数据源，还能按租户切换语义模型本身，从而支撑更复杂的多租户分析平台。