从 JSON 到关系型数据库
数据库可以接受每一次插入，却依然给出错误的采购预算。看看一个放错位置的价格如何破坏产品目录，以及 Entity Enricher 如何将经过审核的身份与关系决策转化为可重复的数据表和更新。
智能体解析你的 JSON 并编写 SQL。Supabase MCP 通过 apply_migration 和 execute_sql 执行这些 SQL。建模、身份标识和重复导入规则必须由你的智能体或应用提供。
你审核一份可复用的 Schema，包括键以及共享或父级归属的关系。引擎据此推导出表、约束和结构索引，随后通过同一模型交付后续的数据变更。AI 帮助提出模型，代码负责执行其规则。
本对比针对的是通过 Supabase MCP 基于 JSON 构建的智能体。设计良好的 Supabase 应用同样可以实现这些防护。下方有缺陷的模型只是对建模风险的示例说明，并非 Supabase 的默认行为，也不代表实测失败率。
这个虚构的目录包含两个产品样本。供应商 SUP-7 以 €12 出售台灯，以 €85 出售书桌。供应商是共享的；价格和交货周期则属于各自的报价。
[
{
"sku": "LAMP-01",
"name": "Reading lamp",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 12,
"lead_time_days": 3
}
]
},
{
"sku": "DESK-02",
"name": "Writing desk",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 85,
"lead_time_days": 14
}
]
}
]在 Entity Enricher 中，这些只是 schema 示例，并非自动数据导入。请检查生成的 schema，将供应商标记为共享、将报价标记为归属父级，然后发布并进行增强或注入匹配的记录。稳定的 SKU 和供应商 ID 为本示例提供身份标识。
错误映射示例
| 列与键 | SQL 类型 |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| 列与键 | SQL 类型 |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
用书桌的报价更新 SUP-7，会覆盖台灯的价格和交货时间。外键是有效的，数据却是错的。这种结构还限定每个产品只能有一个供应商。
采用经过审核模型的 Entity Enricher
| 列与键 | SQL 类型 |
|---|---|
| skuPK | text |
| name | text |
| 列与键 | SQL 类型 |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| 列与键 | SQL 类型 |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
复用同一条供应商记录。每个产品–供应商组合都有各自的价格和交货周期。添加书桌的报价不会影响台灯的报价。
表名和自然键已简化，同步元数据已省略。PK = 主键，FK = 外键。两个报价键共同构成一个复合键。本示例假设每个组合只有一条当前报价；价格历史、币种或数量档位需要额外建模。
采购方需要 100 盏台灯。在第一次与第二次导入之间切换，查看每个模型返回的结果。
错误模型：100 盏台灯的预算
€8,500
高估了 €7,300。你的利润率报表和采购预测现在用的是书桌的价格。
经审核的 EE 模型：100 盏台灯的预算
€1,200
台灯的报价仍为 €12，交货周期 3 天。书桌的报价是单独一行记录。
基于示例数据的说明性计算；不涉及数据库调用或实测财务损失。
每次导入都生成新的供应商 ID，采购记录便会分散到重复的档案中。支出总额和供应商对比将因此失真。
Entity Enricher
声明稳定键可让重复实体收敛。当标签不一致时，可选的语义 ID 会有所帮助，但匹配结果仍需审核。
以 product_sku 开头的联结键无法替代以 supplier_id 开头的索引。随着目录增长，反向查找的开销会越来越大。
Entity Enricher
EE 会为其关系生成结构性索引，包括反向联结查找，并避免冗余的前导前缀索引。其他索引请根据你的实际查询进行调优。
你的 JSON 新增了一个报价字段，目标表或导入 SQL 却没有。新数据要么加载失败，要么永远到不了需要它的报表。
Entity Enricher
已发布的 Schema 同时决定表结构和数据投影。发布前可预览受支持的迁移；不受支持的转换会被阻止。
导入后连接中断。若没有重放规则，重试可能产生重复数据；较旧的更新可能覆盖较新的报价。
Entity Enricher
EE 提供有序投递、基于身份的 upsert 以及修订版本保护。PostgreSQL 客户端在一个事务中应用整个批次，并在提交后确认。
模型返回了 JSON，但某条报价缺少必需的键，或目标端拒绝写入。仅凭一条成功提示，可能掩盖缺失的产品和报价。
Entity Enricher
准入策略可能拒绝某个实体，或省略不完整的子实体。EE 会报告部分结果，并单独跟踪副本投递情况，便于你识别需要修复的内容。
重写未发生变化的报价会消耗数据库资源、造成不必要的索引维护，并让下游的变更处理产生更多噪声。
Entity Enricher
EE 会检测未发生变化的实体状态，并在值未变化时阻止行更新。消费方可通过增量数据流跟踪变更，包括删除。
发布前请审核身份标识、归属关系以及每个字段的含义。EE 让这些决策可执行，但无法证明你的业务模型是正确的。语义匹配可能出错，查询性能也仍取决于负载和数据库规模。
最新一次增强会替换当前状态：缺失的值可能抹掉先前的值，归属报价列表变短则会删除未列出的报价。如有需要，请单独保留历史记录。部分失败或被拒绝的数据需要更正后重新提交；投递状态并不等于自动修复。
当你希望让智能体检查数据库并编写自定义 SQL 时，Supabase MCP 很有用。当同一份数据契约必须持续产出一致的关系型更新时，EE 更合适。你可以将 Supabase PostgreSQL 用作 EE 同步客户端的目标端，前提是连接和数据库权限允许。应用层的访问策略仍需由你自行配置。
审核于 2026 年 9 月 10 日。Supabase 提供迁移功能和可标记缺失索引的 Advisors；EE 的不同之处在于从经过审核的增强 Schema 生成并应用规则。