Da JSON a un database relazionale
Un database può accettare tutti gli inserimenti e fornire comunque un budget di acquisto errato. Scopra come un prezzo collocato nel posto sbagliato corrompe un catalogo prodotti e come Entity Enricher trasforma le decisioni verificate su identità e relazioni in tabelle e aggiornamenti riproducibili.
L'agente interpreta il vostro JSON e scrive l'SQL. Supabase MCP esegue tale SQL tramite apply_migration e execute_sql. Il vostro agente o la vostra applicazione devono fornire le regole di modellazione, di identità e di importazione ripetuta.
Verificate uno schema riutilizzabile, comprensivo di chiavi e di relazioni condivise o di proprietà del record padre. Il motore ne deriva tabelle, vincoli e indici strutturali, quindi veicola le successive modifiche dei dati attraverso lo stesso modello. L'AI aiuta a proporre il modello; il codice ne applica le regole.
Questo confronto riguarda un agente che costruisce a partire da JSON tramite Supabase MCP. Anche un'applicazione Supabase ben progettata può implementare queste protezioni. Il modello errato riportato di seguito illustra un rischio di modellazione: non è un'impostazione predefinita di Supabase né un tasso di errore misurato.
Questo catalogo fittizio contiene due campioni di prodotto. Il fornitore SUP-7 vende una lampada a 12 € e una scrivania a 85 €. Il fornitore è condiviso; il prezzo e il tempo di consegna appartengono a ciascuna offerta.
[
{
"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
}
]
}
]In Entity Enricher questi sono esempi di schema, non un'importazione automatica dei dati. Riveda lo schema generato, contrassegni il fornitore come condiviso e le offerte come di proprietà del genitore, quindi pubblichi e arricchisca oppure inserisca i record corrispondenti. Gli ID stabili di SKU e fornitore forniscono l'identità per questo esempio.
Mappatura errata illustrativa
| Colonna e chiave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Colonna e chiave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Aggiornare SUP-7 con l'offerta della scrivania sovrascrive il prezzo e il tempo di consegna della lampada. La chiave esterna è valida. Il dato è errato. Questa struttura limita inoltre ogni prodotto a un solo fornitore.
Entity Enricher con il modello verificato
| Colonna e chiave | Tipo SQL |
|---|---|
| skuPK | text |
| name | text |
| Colonna e chiave | Tipo SQL |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Colonna e chiave | Tipo SQL |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Viene riutilizzata un'unica riga fornitore. Ogni coppia prodotto–fornitore ha il proprio prezzo e il proprio tempo di consegna. L'aggiunta dell'offerta della scrivania lascia intatta quella della lampada.
Nomi di tabella e chiavi naturali semplificati; i metadati di sincronizzazione sono omessi. PK = chiave primaria, FK = chiave esterna. Le due chiavi dell'offerta formano un'unica chiave composita. Questo esempio presuppone un'unica offerta corrente per coppia; storici dei prezzi, valute o fasce di quantità richiedono una modellazione aggiuntiva.
Un acquirente ha bisogno di 100 lampade. Alterni tra la prima e la seconda importazione per vedere cosa restituisce ciascun modello.
Modello errato: budget per 100 lampade
8500 €
Sovrastimato di 7300 €. Il report sui margini e le previsioni di acquisto utilizzano ora il prezzo della scrivania.
Modello EE verificato: budget per 100 lampade
1200 €
L'offerta della lampada resta a 12 € con un tempo di consegna di 3 giorni. L'offerta della scrivania è una riga separata.
Calcoli illustrativi basati sui dati di esempio; nessuna chiamata al database né perdite finanziarie misurate.
A ogni importazione viene generato un nuovo ID fornitore e gli acquisti si frammentano su profili duplicati. I totali di spesa e i confronti tra fornitori diventano fuorvianti.
Entity Enricher
Le chiavi stabili dichiarate fanno convergere le entità ripetute. Gli ID semantici opzionali possono essere utili quando le etichette variano, con corrispondenze che richiedono comunque una revisione.
Una chiave di giunzione che inizia con product_sku non sostituisce un indice che inizia con supplier_id. Le ricerche inverse possono diventare costose con la crescita del catalogo.
Entity Enricher
EE genera indici strutturali per le proprie relazioni, incluse le ricerche inverse sulle tabelle di giunzione, ed evita indici ridondanti con prefisso iniziale. Ottimizzi gli altri indici in base alle query effettive.
Il vostro JSON acquisisce un campo offerta, mentre la tabella di destinazione o l'SQL di importazione no. I nuovi dati non vengono caricati oppure non raggiungono mai i report che ne hanno bisogno.
Entity Enricher
Lo schema pubblicato determina sia la struttura delle tabelle sia la proiezione dei dati. Visualizzate in anteprima le migrazioni supportate prima della pubblicazione; le trasformazioni non supportate vengono bloccate.
Una connessione cade dopo un'importazione. Senza regole di replay, un nuovo tentativo può creare duplicati e un aggiornamento più vecchio può sostituire un'offerta più recente.
Entity Enricher
EE fornisce consegna ordinata, upsert basati sull'identità e controlli di revisione. Il client PostgreSQL applica un batch all'interno di una transazione e invia la conferma dopo il commit.
Il modello restituisce JSON, ma a un'offerta manca una chiave obbligatoria oppure la destinazione rifiuta la scrittura. Un messaggio di successo, da solo, può nascondere prodotti e offerte mancanti.
Entity Enricher
Le policy di ammissione possono rifiutare un'entità od omettere elementi figli incompleti. EE segnala i risultati parziali e traccia separatamente la consegna delle repliche, così può individuare ciò che richiede una correzione.
Riscrivere offerte invariate consuma risorse del database, aggiorna inutilmente gli indici e rende più rumorosa l'elaborazione delle modifiche a valle.
Entity Enricher
EE rileva lo stato invariato di un'entità e protegge gli aggiornamenti delle righe dai valori invariati. I consumatori possono seguire il feed delta per le modifiche, incluse le eliminazioni.
Prima della pubblicazione, esaminate l'identità, la titolarità e il significato di ogni campo. EE rende tali decisioni eseguibili, ma non può dimostrare che il vostro modello di business sia corretto. Il matching semantico può commettere errori e le prestazioni delle query dipendono comunque dal carico di lavoro e dalle dimensioni del database.
L'ultimo arricchimento sostituisce lo stato corrente: i valori mancanti possono cancellare quelli precedenti e un elenco di offerte possedute più breve rimuove le offerte omesse. Se necessario, conservate uno storico separato. I dati parziali o rifiutati richiedono una correzione e un nuovo invio; uno stato di consegna non equivale a una correzione automatica.
Supabase MCP è utile quando si desidera che un agente ispezioni un database e scriva SQL personalizzato. EE è utile quando lo stesso contratto dati deve continuare a produrre aggiornamenti relazionali coerenti. Potete utilizzare Supabase PostgreSQL come destinazione del client di sincronizzazione di EE, nel rispetto dei permessi di connessione e di database. Le policy di accesso dell'applicazione restano a vostra configurazione.
Verificato il 10 settembre 2026. Supabase offre migrazioni e Advisors che segnalano gli indici mancanti; la peculiarità di EE è generare e applicare regole a partire dallo schema di arricchimento verificato.