平台对象与数据隔离

元数据层

元数据层用于保存平台对象和配置关系。企业、空间、应用、组件、元素、权限、菜单、数据源绑定等信息，都属于平台元数据。它回答的是“谁在什么空间里，可以使用什么应用和元素，以及这些能力应当连接到哪类数据源”。

层级关系可以这样理解：

企业
  └─ 空间
      ├─ 数据源：MySQL / PostgreSQL / ClickHouse ...
      │   └─ 业务库
      └─ 应用
          ├─ 组件能力
          └─ 元素：模型、表单、脚本、报表、页面等

业务数据层

业务数据层用于表达平台能力运行时的数据实际放在哪里。前端“内置数据源”页面中，能看到数据源类型、绑定实例、实例版本、数据库名等信息。

平台后台通过 os-space-tenant 维护空间与数据源、业务库之间的绑定关系。前端页面称为“数据源”，后端实现中对应的数据绑定对象会保存服务实例、服务版本、真实库名和业务类型等信息。

空间
  └─ 数据源
      ├─ 绑定实例
      └─ 数据库名
          └─ 业务表

空间、应用与数据库的关系

空间和数据库的关系按数据源建立。实践上，可以把它理解成：

一个空间
  ├─ 一个 MySQL 数据源      → 一个 MySQL 业务库
  ├─ 一个 ClickHouse 数据源 → 一个 ClickHouse 业务库
  └─ 一个 PostgreSQL 数据源 → 一个 PostgreSQL 业务库

一个空间可以关联多个数据源，但每一种数据源在该空间下只绑定一个业务库。比如同一个空间可以有一个 MySQL 业务库和一个 ClickHouse 业务库；MySQL 表都进这个 MySQL 业务库，ClickHouse 表都进这个 ClickHouse 业务库。

同一空间下，不再按应用拆多个业务库。应用一、应用二、应用三使用同一个 MySQL 数据源时，它们的 MySQL 业务表都在该空间的 MySQL 业务库中；只是表名通过应用编码前缀和组件自带后缀区分。

可以用下面这张二维表理解“数据源/业务库”和“应用”的关系。示例中，空间 A 关联了两个数据源：MySQL 和 ClickHouse。

表中的值表示具体业务表。APP01、APP02、APP03 表示应用编码前缀；Table01、FormData、AnalysisFact、DashboardSnapshot 表示组件或业务语义后缀。真实项目中，各组件会按照自身规则生成或维护表名，但整体关系仍是：空间和数据源决定业务库，应用和组件决定表名。

如果换到空间 B，同样可以有 MySQL 数据源和 ClickHouse 数据源，但它们会绑定到空间 B 自己的业务库。这样即使空间 A 和空间 B 有相同应用、相同组件、相同表名后缀，数据也会因为业务库不同而隔离。

隔离边界总结

DeepFOS 的数据隔离边界可以分成两层理解：

• 空间及空间绑定的数据源，决定业务数据落在哪个业务库中。跨空间、跨业务库，是数据库层面的隔离。

• 空间以下的应用、组件、元素，主要决定业务入口、权限范围、元素归属和业务表命名。它们是逻辑隔离，不天然对应独立业务库。

因此，当业务需要数据库级隔离时，应优先从空间和数据源设计入手：不同组织、项目、环境或业务域，可以放在不同空间中；同一种数据源下，不同空间绑定不同业务库。

当业务只需要区分菜单、权限、页面入口、模型或表单归属时，应优先使用应用、组件、元素和权限配置。它们共享所在空间的数据源和业务库，通过应用编码前缀、组件表名后缀、元素配置和权限控制表达边界。

简单地说：空间以上看数据库隔离，空间以下看逻辑隔离。空间决定“数据放在哪个库”，应用和元素决定“这个库里的表属于哪个业务入口”。