De JSON para uma base de dados relacional
Uma base de dados pode aceitar todas as inserções e, ainda assim, dar-lhe o orçamento de compras errado. Veja como um preço mal colocado corrompe um catálogo de produtos e como o Entity Enricher transforma decisões revistas de identidade e de relações em tabelas e atualizações repetíveis.
O agente interpreta o seu JSON e escreve SQL. O Supabase MCP executa esse SQL através de apply_migration e execute_sql. O seu agente ou aplicação tem de fornecer as regras de modelação, de identidade e de importações repetidas.
Revê um schema reutilizável, incluindo chaves e relações partilhadas ou detidas por um elemento-pai. O motor deriva tabelas, restrições e índices estruturais e entrega depois as alterações de dados subsequentes através do mesmo modelo. A IA ajuda a propor o modelo; o código aplica as suas regras.
Esta comparação abrange um agente que constrói a partir de JSON através do Supabase MCP. Uma aplicação Supabase bem concebida também pode implementar estas salvaguardas. O modelo defeituoso apresentado abaixo é uma ilustração de um risco de modelação, não um comportamento predefinido do Supabase nem uma taxa de falha medida.
Este catálogo fictício contém duas amostras de produtos. O fornecedor SUP-7 vende um candeeiro por 12 € e uma secretária por 85 €. O fornecedor é partilhado; o preço e o prazo de entrega pertencem a cada oferta.
[
{
"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
}
]
}
]No Entity Enricher, estes são exemplos de esquema, não uma importação automática de dados. Reveja o esquema gerado, marque o fornecedor como partilhado e as ofertas como pertencentes ao elemento-pai, depois publique e enriqueça ou injete os registos correspondentes. Os SKU e os IDs de fornecedor estáveis fornecem a identidade para este exemplo.
Mapeamento defeituoso ilustrativo
| Coluna e chave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Coluna e chave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Atualizar o SUP-7 com a oferta da secretária substitui o preço e o prazo de entrega do candeeiro. A chave estrangeira é válida. Os dados estão errados. Esta estrutura também limita cada produto a um único fornecedor.
O Entity Enricher com o modelo revisto
| Coluna e chave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| Coluna e chave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Coluna e chave | Tipo SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
É reutilizada uma única linha de fornecedor. Cada par produto–fornecedor tem o seu próprio preço e prazo de entrega. Adicionar a oferta da secretária deixa intacta a oferta do candeeiro.
Nomes de tabelas e chaves naturais simplificados; os metadados de sincronização são omitidos. PK = chave primária, FK = chave estrangeira. As duas chaves da oferta formam uma chave composta. Este exemplo assume uma oferta atual por par; históricos de preços, moedas ou escalões de quantidade exigem modelação adicional.
Um comprador precisa de 100 candeeiros. Alterne entre a primeira e a segunda importação para ver o que cada modelo devolve.
Modelo defeituoso: orçamento para 100 candeeiros
€ 8.500
Sobrevalorizado em € 7.300. O seu relatório de margens e a previsão de compras passam a usar o preço da secretária.
Modelo EE revisto: orçamento para 100 candeeiros
€ 1.200
A oferta do candeeiro mantém-se em 12 € com um prazo de entrega de 3 dias. A oferta da secretária é uma linha separada.
Aritmética ilustrativa a partir dos dados de exemplo; sem chamadas à base de dados nem perdas financeiras medidas.
Crie um novo ID de fornecedor em cada importação e as compras dividem-se por perfis duplicados. Os totais de despesa e as comparações entre fornecedores tornam-se enganadores.
Entity Enricher
As chaves estáveis declaradas fazem convergir as entidades repetidas. Os IDs semânticos opcionais podem ajudar quando as etiquetas variam, com correspondências que continuam a exigir revisão.
Uma chave de junção que começa por product_sku não substitui um índice que começa por supplier_id. As pesquisas inversas podem tornar-se dispendiosas à medida que o seu catálogo cresce.
Entity Enricher
O EE gera índices estruturais para as suas relações, incluindo pesquisas inversas nas tabelas de junção, e evita índices redundantes com o mesmo prefixo inicial. Ajuste os restantes índices às suas consultas reais.
O seu JSON ganha um campo de oferta, mas a tabela de destino ou o SQL de importação não. Os novos dados não são carregados ou nunca chegam aos relatórios que deles precisam.
Entity Enricher
O schema publicado determina tanto a estrutura das tabelas como a projeção dos dados. Pré-visualize as migrações suportadas antes de publicar; as transformações não suportadas são bloqueadas.
Uma ligação cai depois de uma importação. Sem regras de repetição, voltar a tentar pode criar duplicados; uma atualização antiga pode substituir uma oferta mais recente.
Entity Enricher
O EE fornece entrega ordenada, upserts baseados na identidade e proteções de revisão. O cliente PostgreSQL aplica um lote numa transação e confirma a receção após o commit.
O modelo devolve JSON, mas uma oferta não tem uma chave obrigatória ou o destino recusa a escrita. Uma mensagem de sucesso, por si só, pode ocultar produtos e ofertas em falta.
Entity Enricher
As políticas de admissão podem rejeitar uma entidade ou omitir filhos incompletos. O EE reporta resultados parciais e acompanha a entrega das réplicas em separado, para que possa identificar o que precisa de correção.
Reescrever ofertas inalteradas consome recursos da base de dados, mantém índices desnecessariamente e torna mais ruidoso o processamento de alterações a jusante.
Entity Enricher
O EE deteta o estado inalterado das entidades e protege as atualizações de linhas contra valores inalterados. Os consumidores podem seguir o feed de deltas para acompanhar as alterações, incluindo as eliminações.
Reveja a identidade, a propriedade e o significado de cada campo antes de publicar. O EE torna essas decisões executáveis; não pode provar que o seu modelo de negócio está correto. A correspondência semântica pode cometer erros e o desempenho das consultas continua a depender da carga de trabalho e do tamanho da base de dados.
O enriquecimento mais recente substitui o estado atual: valores em falta podem apagar valores anteriores e uma lista de ofertas detidas mais curta remove as ofertas omitidas. Mantenha um histórico separado quando for necessário. Dados parciais ou rejeitados exigem correção e reenvio; um estado de entrega não é uma reparação automática.
O Supabase MCP é útil quando pretende que um agente inspecione uma base de dados e escreva SQL personalizado. O EE é útil quando o mesmo contrato de dados tem de continuar a produzir atualizações relacionais consistentes. Pode usar o Supabase PostgreSQL como destino do cliente de sincronização do EE, sujeito às permissões de ligação e da base de dados. As políticas de acesso da aplicação continuam a ser da sua responsabilidade.
Revisto a 10 de setembro de 2026. O Supabase disponibiliza migrações e Advisors que assinalam índices em falta; a particularidade do EE está em gerar e aplicar regras a partir do schema de enriquecimento revisto.